> I'm surprised it's that slow! Do you know appx how many file changes
> per revision there are?
About 1-500 files per commit, in average 20-50 files. Most of the revision
number are 50-100. It commits currently 5 text files per second and 0,5 binary
files per seconds. The commit I've started on monday is now at 29 august 2001 :(
The machine is a 2x500 MHz P3/512 MB/Raid 1.
It seems that svn is fast enough, but checking out the old files is so slow:
add or changing 1.20 : java/... takes 0.2-2 seconds, the new commit is fast.
Especially files with many revisions are slow and binarys. (we have a docu file
with rev number 1.1100 and 1-3 additional line per commit, and some pre compiled
.class-Files which may change completely from time to time, and external .class files).
But, also an 1.1-htmlfile, which wasn't changed after this (~1kbyte) took sometimes
3 seconds..., this lies in a docu-Directory with ~1000 files.
May it be depend on the directory size?
> One solution: you can keep track of all commits that came in since you
> started the conversion (just put some trivial script into
> CVSROOT/loginfo to record the path and the new revision number). Then
> after the conversion is done, you can go get all those commits and
> replay them into the Subversion repository manually, or just mail the
> relevant developers and point out to them that the change may not have
> been ported over...
How about a resync in cvs2svn?
- cvs2svn /cvsrepository
- takes two week a normal conversion
- cvs2svn --sync /cvsrepository
- gets all commits after start of the last call
- commiting the new changes
- this step may be repeated several times
- Problems may occure with branches,
because every branches must be checked out again complete
(because it may start in the mid of a branch)
--> can be slow, only <5 branches are changed in two weeks
- and then the import into svn (or took it also long?)
This may be easier than optimizing and also acceptable.
> > - Is a svn2cvs planned?
> Not as far as I know.
Oh, but it may convince more developer and companies, because a backup of a
cvs repository is more safe and svn is not only an one way ticket.
> plan that we recommend in the book. Currently, it just uses the
> top-level directories in the CVS repository as the project roots, but
> it may stop doing that, thanks to a recent thread about how a --prefix
> argument would be more useful.
Can I shift the files in the repository like cvs?
In cvs I can move the files sub dirs deeper, convert it and move it back?
Or should I move the files in directory deeper, and make a svn co
deeper/trunk/* to get rid of deeper/trunk ?
> There's no need for an issue -- branch conversion is all I'm working
> on right now :-).
> Thanks for the reports; I hope you'll keep trying cvs2svn.
No problems, I still runs ;-)
Thx for the answers!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jun 18 15:09:45 2003