Named Branches Lost on hg convert.

[Ewald Ertl]

Hi,

On 09/ 4/11 02:12 PM, Tom Udale wrote:
> Hi Ewald,
>
>> I was just attemting to do the first part - convert cvs to hg by cvs2hg.
>> Everything seemd to work, but the branches had wrong data in the hg 
>> repo.
>> After some searching I found the hint, that on problems converting from
>> cvs to hg
>> you should first convert cvs2svn and than svn2hg.
>> This convertetd the data in the branches correct.
>
> Thanks for the suggestion.  I don't think this is my immediate issue 
> as the cvs2hg conversion seems to work fine in my case: all the 
> expected branches do appear in the initial hg repository.  It is only 
> in my second stage where I am using hg convert that things go awry.
For the others doing also conversions:
     The branches appeard in my conversion run in the hg repository, but 
the content of the branch was wrong ( was a diff to the head version ).

>
> I will take a look however at your approach and see if it makes for a 
> cleaner stage 1 conversion.  There are some odd artifacts of the 
> cvs2hg conversion I would not mind seeing go away.
>
> All the best,
>
> Tom
>
>
>>
>> Hth
>> Ewald
>> -- 
>> Diese Nachricht wurde von meinem Archos-Android-Tablet mit K-9 Mail
>> gesendet.
>>
>>
>>
>> Tom Udale <tom at ionoptix.com> schrieb:
>>
>>     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 pullin
>>       g
>>     "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
>>     
>> ------------------------------------------------------------------------
>>
>>     Mercurial mailing list
>>     Mercurial at selenic.com
>>     http://selenic.com/mailman/listinfo/mercurial
>
>

-- 

Ewald Ertl
Senior Consultant

HartterGruppe
Raimundgasse 25
7400 Oberwart, Austria
Phone: +43 3352-33440-558
Fax: +43 3352-33440-111
ewald.ertl at hartter.com <mailto:ewald.ertl at hartter.com>
http://www.hartter.com <http://www.hartter.com/>

Diese Nachricht und jegliche mit ihr übertragenen Dateien sind nur zur
Benutzung durch den genannten Empfänger freigegeben.

This email and all attached files are authorized only to the named 
recipient.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110905/555691e5/attachment-0002.html>