[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: FW: Subversion

From: Jan Mönnich <Jan.Moennich_at_newtron.net>
Date: 2003-06-18 12:37:32 CEST

Hello karl,

> 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.

> trunk/
> tags/
> branches/
> 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!

> -Karl

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 18 15:09:45 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.