We will be moving to GitHub

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> On Sat, Jan 2, 2016 at 8:48 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Having struggled with Perforce, SVN and CVS, I was hopeful Mercurial
>> would be everything Teamware was.
>>
>> Unfortunately, it wasn't. The big disappointment was the treatment of
>> a repository as the atomic unit.
>
> You'll need to elaborate on this. Is a repository too large or too
> small as an atomic unit?

If a repository contains independent changes, Hg and Git fail to
understand that the changes could be independent and force you to
resolve a merge conflict where no real conflict exists.

The whole philosophy of dependent and independent changes is
complicated; only Darcs has attempted to address the issue
scientifically (<URL: http://darcs.net/Theory/GaneshPatchAlgebra>).
However, Teamware chose an opportune approximation by treating each
file's version history independently.

Teamware's approach works nicely for backporting. You often fix a bug in
the development version and would like to propagate the fix to an older
version (= branch/stream/fork) of the product. In Teamware, the
propagation would not generate a conflict so it doesn't need to be
resolved. No special cherrypicking is involved, and afterwards, you
can't tell if the change was made first to the old
version/branch/stream/fork or the new one.

(Teamware didn't have branches. It always used forks. I believe Hg
is/was the same way. Git, which is what I have to use nowadays, has
branches but I find little use for them.)


Marko