Converting from CVSNT

Arne Babenhauserheide arne_bab at web.de
Fri Jun 26 02:27:26 CDT 2009


Am Donnerstag, 25. Juni 2009 21:29:32 schrieb Michael Haggerty:
> I'm the maintainer of cvs2svn.  Did the unlabeled branches appear in
> SVN, or only after converting to mercurial?  If the former, I would
> appreciate it if you would report this as a bug on the cvs2svn mailing
> list.

Then first, please accept my thank you. cvs2svn is a great program! 

(Yes, I know I'm not the one who wrote the original question, but I wanted to 
say thank you anyway :) ). 

> With the latest trunk version of cvs2svn, it should also be possible to
> convert directly from CVS to the hg-fastimport format by starting from
> the "cvs2hg-example.options" options file.  However, there haven't been
> many reports about how well this works, so if you try this, please
> report your experiences.

I tried that but gave up, because the fastimport extension wasn't up to teh 
task at that time (a repo with about 600.000 changesets). 

Afterwards I tried first doing a git fastimport, but that resulted in a 
corrupt git repository. 

So I'm now back at the basic usecase: converting to svn and then converting 
the svn repository to hg. It's also what feels most robust to me - my computer 
already worked for about two weeks straight (when I add all together) and I 
had to throw that work away, so I'm now going the safe path. 

And incremental conversions to SVN using only the output pass (16) is great! 

Here are the scripts I use: 

--- --- --- --- --- --- 

$ cat convert-tree-to-hg.sh 
#!/bin/sh                                                             

# pass 1
cvs2svn -s /portage/portage-tree.svn -p 1 --skip-cleanup --username=cvs2svn --
encoding=utf_8 --fallback-encoding=ascii --retain-conflicting-attic-files vcs-
public-cvsroot/gentoo-x86/                      
# pass 2 - 12 (all short)                                                                             
cvs2svn -s /portage/portage-tree.svn -p 2:12 --skip-cleanup --username=cvs2svn 
--encoding=utf_8 --fallback-encoding=ascii --retain-conflicting-attic-files 
vcs-public-cvsroot/gentoo-x86/                   
# pass 13 (sorting)                                                                                   
cvs2svn -s /portage/portage-tree.svn -p 13 --skip-cleanup --username=cvs2svn 
--encoding=utf_8 --fallback-encoding=ascii --retain-conflicting-attic-files 
vcs-public-cvsroot/gentoo-x86/                     
# pass 14 and 15                                                                                      
cvs2svn -s /portage/portage-tree.svn -p 14:15 --skip-cleanup --
username=cvs2svn --encoding=utf_8 --fallback-encoding=ascii --retain-
conflicting-attic-files vcs-public-cvsroot/gentoo-x86/                  
# pass 16: output                                                                                     
cvs2svn -s /portage/portage-tree.svn -p 16 --skip-cleanup --username=cvs2svn 
--encoding=utf_8 --fallback-encoding=ascii --retain-conflicting-attic-files 
vcs-public-cvsroot/gentoo-x86/                     

# convert from svn to hg
svnserve -d -r /portage/portage-tree.svn                                                              
svn co svn://127.0.0.1/ /tmp/portage-tree.svn-co
time hg convert /tmp/portage-tree.svn-co portage-tree.hg

--- --- --- --- --- --- 

Since my computer died of the heat while I ran this script the first time (I 
got 18.000 revisions) I'm currently doing first the output to a dumpfile and 
then importing that to a svnrepo via

	cvs2svn -s /portage/tree.svndump -p 16 --skip-cleanup --username=cvs2svn 
	--encoding=utf_8 --fallback-encoding=ascii --retain-conflicting-attic-files 
	vcs-public-cvsroot/gentoo-x86/ 

	svnadmin create portage.svn
	cat /portage/tree.svndump | svnadmin load portage.svn

First doing a full dump and then importing seems far faster than interleaving 
the two (the dump gets about 10 to 20 revisions a second - less than half an 
hour or so brought back the old conversion state which originally took many 
hours. Still I expect about 15 hours for the dump). It could have been just 
different access patterns to my disks, though. 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://selenic.com/pipermail/mercurial/attachments/20090626/b5ba1224/attachment.pgp 


More information about the Mercurial mailing list