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