Named Branches Lost on hg convert.

Tom Udale tom at ionoptix.com
Sat Sep 3 22:25:17 UTC 2011


Hi All,

I have been continuing on my cvs->hg conversion odyssey and thought I 
was about to be able to declare complete victory when I noticed one 
small (ehem) problem.

To recap: the goal is to convert a large CVS repo to a hg repo with a 
number of sub-repositories.  I am inserting .hgeol, .hgignore, .hgsub 
and .hgsubstate files into the history of final repo using hg convert.

My process is as follows:

Stage 1: I start with a cvs repo.  Divide it into a number of 
independent repositories via cvs2hg.  Each repository gets initialized 
and then the correct .hgeol and .hgignore files as the first commit. and 
then I cvs2hg on top of this initial repo via --existing-hgrepos.  This 
gives me a series of hg repos that are "well behaved" with respect to 
eol and ignore.

Stage 2: I then start pulling "slices" off my main repo using hg convert 
--rev.  Each "slice point" is at an important event that needs some 
adjustment: add a sub repo, update sub-repo states to a common named 
tag, etc.  I keep adding slices until the entire repo is reconstituted 
in the destination with all the .hgxx files in the history pretty much 
as if they had grown there organically.  This is all done via a script 
so it can be re-run with tweaks as many times as needed.

Everything is going swimmingly so far except I noticed yesterday that 
only the default branch is getting pulled into the stage 2 destination 
repo.  It took me a while to notice because it was doing unnamed 
branches on default perfectly (convert is a champ) and it took quite a 
few slices to hit my first named branch.

I initially thought (and still am suspicious) that it was because I was 
doing these small slices and perhaps some sort of sorting was pushing 
the branches to the end and out of my range.

I finally did a complete bare

hg convert source dest

with no options to convert the whole darn thing and that _did_ bring in 
all the named branches.

So then I did a few tests of converting very big slices (5k of 18k 
change sets) using the defaults, --sourcesort and --datesort: still no 
named branches.  These tests had no "historical fixes" of any sort, just 
a straight convert from the source to the dest.

So I don't quite know what to think.  I cannot find any docs that 
indicate named branches are skipped.  Quite the opposite.

I still think it is something to do with the sorting and an incomplete 
range.  However, I though for sure that sourcesort tackle that problem. 
  I understood that to mean by "sort by source revision number" and 
indeed that looks like that is what it means if I look at the source 
code.  Thus I would have figured that converting the first 1000 or 5000 
revisions would have captured a named branch at revision 84, but it does 
not.  It and its children are just gone.

There is no mention of that hash in either the shamap or in the captured 
output of the command.  So it seems to be getting filtered out before 
anything happens in terms of writing out the destination.

Any thoughts on this??


Best regards,

Tom





-- 
Tom Udale
--------------------------
IonOptix LLC
309 Hillside St.
Milton, MA 02186
(617) 696-7335
--------------------------
tom at ionoptix.com



More information about the Mercurial mailing list