Strategies for push/merge problem?

Greg Lindahl lindahl at pbm.com
Mon Jul 14 15:14:36 CDT 2008


On Mon, Jul 14, 2008 at 11:38:55AM -0500, Matt Mackall wrote:

> If we have n people trying to update the counter
> themselves, they'll all have to first get the counter, update it, try to
> put it back, and if it's changed in the mean time, they have to start
> over.

This is a fine example of the case where there are genuine conflicts
over changes. But the people asking for this feature don't have
genuine conflicts.

If the merge tool is smart enough to resolve the conflict without
human help, then why should Mercurial require extra hoop jumping for a
false conflict?

It seems to me that the "don't push" religion is a separate one from
the DVCS religion. Yes, "push" does break down with large groups, but
that size would be a lot bigger if Mercurial used the same algorithm
as merge tools to determine that there's a merge conflict.

> If instead we have one person who's job it is to pull, he can simply
> poll each user in turn and get their counter update and move on, without
> ever having any conflicts, even if there are thousands of users. More
> importantly, no one ever needs to wait.

There is waiting: the developer has to wait for the single person
doing pulling to get around to pulling new changes. ("can you please
pull my bugfix?" "hey, you didn't pull from me yet, and this is an
important fix!")

There's also a merge problem: the person best equipped to merge real
conflicts are the developers who changed the code, not the single
person whose job it is to pull. ("hey Fred and Bob, I don't understand
these 2 conflicting changes, can you please come by my cube and tell
me how I should fix it?")

> ps: The Linux kernel used to do something very similar to the scenario
> above when counting network packets, etc. It all worked fine until
> someone showed up with a multi-million dollar machine with 1024 CPUs and
> networking interfaces. With all 1024 CPUs trying to update the same
> counter, not much actual work got done. Switching to a pull model
> naturally made the problem vanish.

It could also have been solved by pushing groups of counts, e.g.  push
an update every ncpu/1024 seconds. There's more than one way to do it,
and not every system has to be engineered for millions of updaters.

FWIW, many highly-parallel systems with central databases push groups
of counts. Most big websites work that way.

-- greg




More information about the Mercurial mailing list