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
directories.
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
svn:externals.
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.
HTH,
-Arcege
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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393050
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-09 20:58:49 CEST