[PATCH] convert with clonebranches and splicemap fails

Patrick Mézard pmezard at gmail.com
Wed May 11 02:56:15 CDT 2011


Please keep the list in copy.

Le 11/05/11 07:41, Peter Rebholz a écrit :
> On Tuesday, May 10, 2011 at 4:14 PM, Patrick Mézard wrote:
> Le 10/05/11 06:11, Peter Rebholz a écrit :
> 
> 
>     You are correct to say the failure is caused by a data dependency issue, but it should be addressed by taking the splicemap constraint in account when deciding the order in which the revision should be converted instead of trying to fix it after the fact. The splicemap really modifies the graph being converted by changing the parents of some revisions and this should be taken in account in convcmd.toposort() instead. To illustrate this, here is your test rewritten with mercurial repositories for simplicity. The problem can be reproduced without the clonebranches option. A straightforward solution would be to update the revision graph with the desired parents but this is made harder by splicemap accepting parent revisions in either source or destination format. Also, I have not checked the code to see whether the source needs to have the original parents available.
> 
> Patrick,
> 
> Thank you for taking the time to review the patch. I agree with your assessment that the sorting should take the splicemap into account. This would certainly make things easier for new comers as they would be less likely to receive the somewhat confusing unknown revision error message. It would also alleviate the need to use --datesort in certain cases when splicing merges and resolve the issue you pointed out.
> 
> With regards to clone branches, my approach seemed logical because the conversion I was working on at the time was trying to produce a nicely structured Mercurial repository from Subversion repository. Since the splices were all merges it made sense to me to make the conversion work like the typical Mercurial workflow of pull and merge. However, if I understand you correctly, a properly sorted revision history wouldn't require this extra pull step because the revisions would be applied to the sink in a way that clone branches could be made from their parent branch at their last common revision.

Yes, that's the idea.

What looked wrong to me is the hg sink already has code to pull from siblings when parent branches are missing, and the code did not seem especially wrong to me. Also, I have to say I am not really interested in the "clonebranches" feature which I consider more than a hack than a reasonable feature. It is much more efficient to convert into a single tree then loop over the available branches and clone/pull individual branches with a post conversion script.

> Take the following source repository for example:
> 
>     /-3---5-6\ <-- Release 1
> 0-1-2---4-----7 <-- Default

You cannot trigger the issue if 7 is already a real merge of 4 and 6 because the toposort will handle that case. Let's modify it slightly:

    /-3---5-6 <-- Release 1
0-1-2---4-----7 <-- Default

Now, there is no reason to convert 6 before 7 since there is no explicit dependencies between the two, so a straightforward conversion will probably handle the revision in the following order:

0 1 2 4 7 3 5 6

because by default convert works in DFS order to optimize storage compression efficiency.

If you add a splicemap saying:

7 <- (6, 4)

this will fail because 7 is converted before 6, so the latter cannot be used as its parent.

The solution is obviously to take that in account when sorting the revisions and convert them in the following order:

0 1 2 4 3 5 6 7

which is the same order which would be used in your original example where 7 really has 6 and 4 for parents.

--
Patrick Mézard


More information about the Mercurial-devel mailing list