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

RE: Move from CVSNT to SVN?

From: Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be>
Date: Fri, 11 Sep 2009 11:23:04 +0200

Just adding my .02:

We migrated from CVS(notNT) to SVN half a year ago. I agree with most of the things already said (advantages like atomic commits, renames/moves, active development, a lot of great features, ...). It's usually a very good "upgrade".

But to balance things a little, I'm adding some more critical sounds:

- SVN is slower than CVS for "log" and "annotate" for a particular file. This is understandable given the difference in architecture (CVS has all the information in that single ,v file; SVN has to plough through a huge pile of revisions to get the info). Usually it will still be ok, and you won't notice the difference. But we have some really horrible edge cases here: a 2MB xml file with 6000 revisions (and counting).
* Log: 5 seconds with CVS, 4 minutes with SVN
* Annotate: 17 seconds with CVS, connection timeout after 50 minutes with SVN

As I said, this is an extreme case. For normal source files with maybe a couple hundred revisions it's fine.

- Unlike with CVS, there is no easy way in SVN to see which tags (or branches) are "attached" to a particular version of a file. You can see in a tag or branch where the file was "copied from", but you can't see in trunk where a file was "copied to".

- As you hinted yourself, the rename/move support is limited. Of course it's already a huge step forward from CVS (no rename/move support). But there are some limitations (which can come up regularly when you tend to refactor often, rename and move things around, ...):
* There is the "tree conflict" thing (as someone else already commented). I.e., when moving/renaming, tree conflicts will happen (on merging branches, or simply when someone else commits renames/moves, while you were modifying the files locally or something like that). As of SVN 1.6, tree conflicts are detected (which is great). But there is no built in tooling to help you resolve them.
* You can confuse SVN's working copy by doing too much renaming/moving at once. For example see http://subversion.tigris.org/issues/show_bug.cgi?id=3429 and http://subversion.tigris.org/issues/show_bug.cgi?id=3474. Hopefully this will be improved when 1.7 gets out (which includes a rewrite of the working-copy stuff). For now, you just need to be aware of the limitations and be careful (committing in between helps)

But all in all, I think the advantages definitely outweigh the negative points (and since it's actively developed, and has a very active user community, I trust that it will keep on improving).



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-11 11:24:01 CEST

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

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