[PATCH 2 of 2] transplant: check that changeset was not applied more carefully

Jesse Glick jesse.glick at sun.com
Thu Nov 26 11:51:40 CST 2009


Alexander Solovyov wrote:
> Previously, if you have deleted .hg/transplant/transplants file, attempt to
> transplanting already applied patch will result in merge errors. Patch fixes
> this problem by regenerating this file is it does not exist.

I haven't tried it yet, but it seems this would still fail to improve the behavior if you:

1. Do some transplants yourself.

2. Pull some transplanted changesets made by someone else in a remote repo.

3. Accidentally attempt to re-transplant a cset that someone else had already transplanted.

...since in step 3 there would already be a local transplants file and the code would just assume it is complete when really it is missing transplants from step 2.

This might sound like a corner case, but at least in some workflows it could be quite common. Your team creates a clone to stabilize a product release, transplanting 
tested fixes from a development repo into the release repo. You make a personal copy of the release repo when it is branched, and backport at least one such fix. Your 
colleagues backport a lot more, which you synchronize with in the usual ways. Due to a lack of communication you try to backport something that was already backported; 
rather than getting a polite message telling you this, you get a confusing merge error, or at least wind up with two transplants for the same original changeset. The same 
problem could arise if you are instead forward-porting fixes from release to development.

One way to correct this problem would be for the extension to listen for incoming changegroups and just delete the transplants cache. This could result in the cache 
rarely being used at all, though since transplant is a relatively rare operation in my experience, I think it would be better to be correct than fast. Maybe things are 
even fast enough without a cache - certainly would be preferable to the current state, where the cache is actively wrong.

Alternatively, you could record in the transplant cache the revision number of tip when it was last refreshed. Do _not_ append to the cache after transplanting. When 
preparing to transplant and reading the cache, scan for transplants only in changesets newer (by revision number, not history graph) than that old tip, and 
correspondingly update the cache. This way you pick up transplants made since the previous cache refresh (either by the local transplant done immediately afterward, or by 
pulled changegroups), but do not need to search through the whole changelog. This would be reliable unless you used strip/rebase/etc. to destroy history. A more complex 
but perhaps more robust fix would be to record all repo heads when refreshing the cache, and prune the search at the previously recorded heads.

By the way, your patch is I guess an attempt to fix an open tracker issue: http://mercurial.selenic.com/bts/issue1210



More information about the Mercurial-devel mailing list