We will be moving to GitHub

[Chris Angelico]

On Sat, Jan 2, 2016 at 10:22 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
> 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.

I don't think you understand the meaning of "merge conflict", then. A
merge conflict is when you cannot simply merge the changes. If the
changes are on separate files, neither git nor hg will find this to be
a conflict, and the merge will happen automatically. Alternatively,
you can rebase rather than merging (git's term; Mercurial has a
similar concept for saying "put my private changes on top of the
history", but I can't remember the name), which again will succeed
automatically if the changes are to different files. Even better, the
merge/rebase will generally succeed even if the changes are to the
same file, as long as they're to different parts of it.

Play to a tool's strengths rather than its weaknesses, and you'll find
life a lot less frustrating. I'm fairly sure you could use the same
workflow with git as you were accustomed to with Teamware, only with a
few different names for things. And most likely Mercurial too, but
again, there'll be different names. Maybe you'll use branches for what
you used to use forks for, or maybe you'll have multiple clones of the
same repository, or maybe some other arrangement. Get to know some of
the myriad ways you can use modern source control systems, and find a
workflow that suits you.

ChrisA