[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: Michael P. Reilly <arcege_at_gmail.com>
Date: Wed, 9 Sep 2009 14:57:25 -0400

I won't say from a CVSNT, but from a CVS viewpoint, there are a large number
of reasons. Here are but a few.

   1. The 'Attic' - trying to handle moving/renaming files, creating files
   on a branch, deleting files from the repository.
   2. You already mentioned versioned directories.
   3. Searching a repository for one commit that happened last week (can't
   always rely on cvs+history), especially including a large number of
   4. Atomic commits - probably the #1 reason developers have claimed a
   desire to switch in my experience (but probably not their biggest pet-peeve)
   5. Conflict resolution - more options when conflicts are found and how to
   handle them; I may not want the file with the tokens in them, so Subversion
   supplies instances of the local copy, the branch copies and the merged copy.
   6. Deltas of binary files - all files are stored as delta'ed files,
   including binary files, not just text files; this *can* be a space saver
   on the repository side (depending on how much has changed).
   7. Offline support and better network bandwidth - Subversion has a
   philosophy that disk space is cheap and bandwidth is expensive: a copy of
   your checkout is kept on disk to help speed up operations like svn+diff,
   svn+status, svn+revert. Also, since there is already a copy on disk of what
   you first checked out, the system knows exactly what you changed and can
   sent only those changes instead of the entire file (something that CVS does
   only on some files).
   8. Transactions - not the same as atomic commits, CVS has no notion of a
   changeset. Even if you perform a commit at the same time, the only thing
   binding the changes to the different versioned files together is the comment
   string and the relative time the commits are made. With Subversion, there
   is a single commit entry made that includes all files. Many managers find
   this very valuable. This can be simulated with 3rd-party tools in CVS.
   9. Repository moves - when a repository server needs to move (it does
   happen), developers either need to check in all their code or each CVS/Root
   and (depending on the release of CVS) each CVS/Repository file in their work
   areas will need to be updated - this could be tens of thousands of files per
   developer: 1 or 2 per directory for each checkout. In Subversion, there is
   a command to tell the workspace to point to the new server and the workspace
   does not need to change.
   10. Hot backups - since Subversion is a database, there is the internal
   concept of locking the Subversion database to take 'hotcopy' backups which
   will take a copy of the repository, ensuring no changes could be made, so
   you can safely backup the copy. This is for HEAVY use Subversion
   repositories. Ones that get light or no use at night would have no problems
   being backed up directly (the same as CVS).
   11. I've done a little performance testing on repositories of ~500k
   revisions. I saw no degradation in the performance. If you have ten years
   of checkins, then you will easily be getting up into that range and
   performance should be a consideration for you.

There are some drawbacks to Subversion as well.

   1. The 'branches', 'tags', 'trunk' structure is not typical of a version
   control system and a little hard for some developers/users to get used to:
   'directories as branches?' For some projects where I know there will never
   be any divergent development or tagging, then I sometimes forgo the whole
   structure and just have a single directory for them... but that has usually
   been with marketing types.
   2. Revision mumbering scheme is also difficult for some developers/users
   to get used to; I like to explain it as layers of onion paper being laid on
   top of each other in mechanical drawings, but each looking specific
   time-slices in the repository.
   3. CVS will honor checkouts in subdirectories, but Subversion will say
   that the subdirectory is not part of the current working copy. This is
   supposedly to not confuse URLs and revisions and to force the use of
   4. Subversion uses a database and CVS used flat files which made 'fixing'
   CVS much easier. However, in the last four years of managing dozens of
   large Subversion repositories through power failures and server crashes, I
   haven't really had to 'fix' a Subversion repository.
   5. Moving a files/directories between Subversion repositories - goes back
   to Subversion using a database. You need to export the data from the
   database, possibly changing pathnames, and then importing the data into the
   new database. There are great tools to do things, but it helps if you know
   good "power tools" as well.

These lists are not exhaustive, even even for me, but gives you some idea of
the pros and cons from one person's experience.

In many ways, both are equivalent, so don't get hung up too much. But one
last thought for you: Subversion was to be the next evolution of a version
control system by CVS's own development team.


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

> Hi,
> I'm considering a switch from CVSNT to SVN and am looking for feedback from
> people who have made the switch in the past. Are you happy with your new
> choice? Does SVN allow you to be more productive than CVS? What prompted
> the move? What features are you able to use with SVN that you didn't have
> 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 to
> 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 that
> SVN allows for directory revisioning, but I am assuming that there must be
> 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 just
> looking for feedback from experienced users who have made the transition
> and
> recommendations or warnings of things to be aware of prior to making a
> decision.
> 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!
> Eric
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393030
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].

There's so many different worlds,
So many different suns.
And we have just one world,
But we live in different ones.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-09 20:58:49 CEST

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