[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: Eric B. <ebenze_at_hotmail.com>
Date: Mon, 14 Sep 2009 10:26:43 -0400

Hi David,

Thanks for the feedback. I know that svn has all but replaced CVS in the
last years. I know that the CVSNT developers (March-Hare) have been
actively working on it, as well as a new replacement that is supposed to
support all stnadard clients (CVS, SVN, etc), but development seems to be
quite slow compared to svn.

Hence the reason to start to question if sticking around for something like
that is worthwhile, or if it is worth the effort to switch to svn.

Thanks for the insights!

  "David Weintraub" <qazwart_at_gmail.com> wrote in message
  Sorry I'm late to the conversation, but here's my take:

  We moved from CVS to Subversion, and we did it because I liked the
features in Subversion that were completely missing in CVS. Subversion can
use Apache as a protocol which means I can use LDAP that connects to my
Windows server. Before, we were using pserver and I had to manually give
everyone an account. Now, when a developer gets their Windows account, they
have Subversion access.

  Subversion handles our end-of-line issues. In CVS, the client was suppose
to do this, but we always ended up with mixed EOL styles. In Subversion, I
can make sure shell scripts have the UNIX EOL style set. I can also use
hooks to lock branches when they aren't in use (it's much harder to do in
CVS), and developers can easily find their change set and back out their

  We do continuous builds, and CVS taking 30 to 40 minutes to label was
hurting our ability to build after every change. Subversion can tag a build
in less than a second. What use to take 50 minutes now can be done in 10
minutes. And, really I don't even need to create a tag if I know the
Subversion revision number.

  There's little things like a developer being able to see a list of
branches and tags without having to examine every file in the repository.
What use to take 20 minutes in CVS can be done in a few seconds in

  Subversion and CVS use similar workflows, so they're fairly compatible in
that area. We didn't have to completely redo our entire build infrastructure
because we changed from CVS to Subversion. Something that you might have to
do if you moved to say ClearCase.

  To me, if you're using CVS, you might as well upgrade to Subversion. CVS
has had no active development in the last decade. Subversion has replaced
CVS in that respect.

  On Wed, Sep 9, 2009 at 10:43 AM, Eric B. <ebenze_at_hotmail.com> wrote:


    I'm considering a switch from CVSNT to SVN and am looking for feedback
    people who have made the switch in the past. Are you happy with your
    choice? Does SVN allow you to be more productive than CVS? What
    the move? What features are you able to use with SVN that you didn't
    with CVS? From the flip side, are there reasons you regret making the
    change? Are there things in SVN that are more complicated or difficult
    acheive than CVS? Or are some tasks with SVN more error-prone?

    I know that a great portion of the OSS community has switched to svn
    (apache, sourceforge, etc), so I'm trying to find out "why". I know
    SVN allows for directory revisioning, but I am assuming that there must
    more than just that to promote such a large change over.

    I'm not trying to start a war as to which solution is "better"; rather
    looking for feedback from experienced users who have made the transition
    recommendations or warnings of things to be aware of prior to making a

    I have a large CVS repository from 10yrs of code that I would be moving
    over, so it isn't a decision that I'm going to be making lightly.

    Thanks for any insight!



    To unsubscribe from this discussion, e-mail:

  David Weintraub


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 16:29:05 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.