Strategies for push/merge problem?

[Peter Arrenbrecht]

We all heard that Matt is not interested in the push approach. Fair
enough. So the question is, do sufficiently motivated people want to
take this into their own hands? I think it's not that hard to do as a
client and server extension, which could alleviate both the merge race
and the mergeful history problems. But, of course, a legimitate
question is if it stands a chance of getting official extension status
(Matt?).

I do believe it would make the transition to Hg easier, even if it
does not scale indefinitely. And it would make Hg even more versatile.

So - to continue a previous thread - how about the following for a
plan to implement server-based `hg pushmerge` and `hg pushrebase` (or
whatever better names we can find)?

It can be done with current tools (rebase is coming), but for best
performance, let's assume we can provide these currently missing
pieces:

(a) a dedicated local overlay repo that uses the parent's config (so
hooks are the same) and stores only increments to parent revlogs (so
it is extremely lightweight),
(b) make conflict-free merging possible without a working copy,
(c) dito for conflict-free rebasing.

Given the existing OverlayRepo code and the latest work on
working-copy-free convert, I think this is not unreasonable.

Then I think we could implement `hg pushmerge` on the server like this
(pseudo-code):

	inbundle = read client's changes
	wlock = repo.wlock()
	# no one else is pushing or integrating now
	try a straight push of inbundle
	if no new heads:
		return
	# straight push failed and rolled back
	intrepo = VeryLightweightClone(repo, '.hg/integrate')
	try:
		intrepo.unbundle(inbundle)
		if not intrepo.conflictfreemerge():
			return failure
		repo.pull(intrepo) # should succeed now
		clientrepo = BundleRepo(repo, inbundle)
		outbundle = intbundle.bundle(everything_not_in=clientrepo)
		return outbundle # stream outbundle back to client
	finally:
		intrepo.delete()

`hg pushrebase` would be similar, but attempt a conflict-free rebase
instead of a merge. And the client would strip away the old changesets
when receiving a return indicating a successful rebase. Of course, the
use of pushrebase means you should not have shared the changesets
previously. But even if you did, someone with a stray head due to this
can simply strip it, or merge it back into the rebased series to make
the elimination pushable.

While we don't have the VeryLightweightClone and working-copy-less
merge/rebase, we might instead use a proper clone in .hg/integrate,
where we

	copy repo's config to intrepo (assuming no relative paths)
	intrepo.pull(repo) # bring it up to date
	intrepo.update -C tip
	lastgoodtip = intrepo.tip
	try:
		...
	except:
		intrepo.strip(lastgoodtip+1)

All this while we're holding the wlock on the main repo, of course.

Any takers?
-parren

On Mon, Jul 14, 2008 at 9:44 PM, Jason Orendorff
<jason.orendorff at gmail.com> wrote:
> On Mon, Jul 14, 2008 at 2:17 PM, Johannes Stezenbach <js at sig21.net> wrote:
>> On Mon, Jul 14, 2008 at 12:24:13PM +0200, Roman Kennke wrote:
>>>
>>> Also: I know that the centralized approach is not the most HG-ish way to
>>> work with HG. But I also think that a lot of people are using it that
>>> way, and it shouldn't be so difficult to do. One nice thing about HG is
>>> its flexibility, but this needs to be easier.
>>
>> I happend to come across the Mozilla site recently, maybe
>> it is of interest because Mozilla is a largish project:
>>
>> http://developer.mozilla.org/en/docs/Mercurial_FAQ#Push_to_the_central_repository
>>
>> It would be interesting to hear how this works out in practise
>> for the Mozilla team. If someone finds out please let us know.
>
> We've been using Mercurial in this centralized way for a while now,
> and yes, this pull-update-commit-merge race condition is a pain,
> especially given the volume of check-ins.  We've started discussing
> how to fix this.  It's sure to be a hot topic at the Firefox summit at
> the end of this month.
>
> One possibility that has come up was to have an automated system that
> continually polls certain public repositories (perhaps the Mozilla
> module owners would have public "outgoing" repositories) and
> automatically pulls, merges, builds, and tests new heads as they
> appear (whenever automatic merging is possible).  Only revisions that
> pass tests would be pushed to the system's own public repo, which
> could be the official trunk.  I don't know that anyone has actually
> thought this through or decided to do it "soon" though.
>
> In the short term, we're still working on finding ways to make a
> highly mergeful changelog readable and navigable.
>
> --
> Jason
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>