Bug 1748 - splicemap fails due to improper sort on hg convert
Summary: splicemap fails due to improper sort on hg convert
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Patrick Mézard
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-20 14:36 UTC by Bruce Frederiksen
Modified: 2012-02-10 18:00 UTC (History)
4 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bruce Frederiksen 2009-07-20 14:36 UTC
Using --splicemap with `hg convert` trying to convert svn to hg fails
because the svn parent revs specified in the splicemap are not converted
prior to the child rev.

In other words, it doesn't appear that the splicemap info is factored into
the sort algorithm that determines the order that the revs will be converted.

Adding the --datesort option helped it to get further, but it still failed
on a later mapping.
Comment 1 Bruce Frederiksen 2009-07-20 17:21 UTC
I was mistaken about --datesort.  That did fix it (it failed earlier with
--datesort due to a problem in my splicemap file).

But without the --datesort option, it still doesn't work.  I think that it
still makes sense to add the splicemap dependencies to the default sort
algorithm.  So I'm leaving this bug open.
Comment 2 Patrick Mézard 2009-07-22 13:41 UTC
Are you using --splicemap to splice yet to be converted revision onto yet to
be converted other revisions? It's often used to splice converted revision
onto existing mercurial one.
Comment 3 Bruce Frederiksen 2009-07-22 15:14 UTC
Yes, I was converting an entire svn repo to hg.

The convert tool doesn't look at the svn:mergeinfo properties, so I went
through these by hand (rather tedious) to create the splicemap.  I thought I
would need this info in hg so that hg merges in the future would have the
correct common parent (I have 2 branches + trunk in svn).

I didn't see anything in the hg documentation on convert about using splice
to map new converted revisions onto existing hg revs.  I wouldn't think it
would make sense to run convert to add revs from somewhere else onto
existing hg revs.  Unless you're trying to keep two different VCS systems in
sync???

I'm thinking I just want to do this convert once, and then abandon the svn
repo...

Anyway, to get back to the specific bug report, the slicemap dependencies
were all new converted revs (both child and parents specified using the svn
rev numbers).  Not adding these dependencies to the default convert sort
fails (i.e., without --datesort) because the sort tries to convert the child
before one of the parents has been converted...
Comment 4 Patrick Mézard 2009-07-23 01:44 UTC
I have never seen such usage but it makes sense. I can confirm that
splicemap entries are not taken in account.

Last time I have seen someone use splicemap it was with an svn repository
having a branch layout the convert extension could not make sense of. So it
converted branches separately and combined everything afterwards.

Which is something you probably can do if you do not want to wait for a fix
(I cannot see a simple solution for this right now).
Comment 5 Patrick Mézard 2012-02-10 12:24 UTC
Reopening as someone had the problem on IRC. Patch in progress.
Comment 6 Patrick Mézard 2012-02-10 15:42 UTC
Patches submitted here:

  http://selenic.com/pipermail/mercurial-devel/2012-February/037982.html
Comment 7 HG Bot 2012-02-10 18:00 UTC
Fixed by http://selenic.com/repo/hg/rev/d75aa756149b
Patrick Mezard <patrick@mezard.eu>
convert: use splicemap entries when sorting revisions (issue1748)

(please test the fix)
Comment 8 Bugzilla 2012-05-12 09:01 UTC
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:01 EDT  ---

This bug was previously known as _bug_ 1748 at http://mercurial.selenic.com/bts/issue1748