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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html