Re: Newbie grief

[Rich Pixley <rich.pixley@palm.com>]

On 5/4/12 08:56 , Mark Brown wrote:
> On Thu, May 03, 2012 at 01:52:35PM -0700, Rich Pixley wrote:
>
>> It's not just hg.  It's other source code control systems as well.
>> Check out any of the other daggy guys.  So sure, I'll admit a bias
>> for current technology over older tech.
>
> I'm still not sure what's missing here without a central server?   The
> other DVCSs I've used (which don't include hg) do require that the user
> trigger a merge operation somehow; they don't magically go and merge
> things without being asked.

Nor does hg.  Rather, it allows the collision to be tracked within the 
source code control tool so that anyone who wants to see it can do so, 
and so that anyone who wants to merge it can do so.  The data flow paths 
for collisions and proposed changes can follow precisely the same paths 
as any other code changes.  No meta channel is required.

This is a different situation from either the one where I, specifically 
me, must merge or the one where I intend my changes to stay separated 
from other development, (a new "branch").  The situation with multiple 
heads allows the merge, the branch, even the decision about whether to 
merge or branch, to be delayed indefinitely.

The fact that it allows for this also allows for a number of different 
repository network architectures, all of which are blocked in git 
because of the push problem.  In git, those decisions must be made 
_before_ the push.

There's also a possibility of nonterminating merges.  That is, if my 
team is making changes faster than you can merge them, then you'll never 
get to push your changes.  With dual heads, you still can.  And then 
anyone who wants to can merge them.

--rich