Wow - thanks for the thorough writeup. It definitely helps me a little. I
can understand a lot of the points; the "Attic" is probably one thing that
drives me nuts in CVS. I find it incredibly hard to ressurect and to see
files in the Attic, although, in theory, it should be relatively easy.
Browsing the Attic as well is a task in frustration alone.
The concept of Atomic commits is really amazing, especially if you work in
large dev teams that cannot easily communicate with each other and who are
constantly updating their sandboxes. However, in practice, I have to say I
haven't really found the need for Atomicity that lacking in CVS.
From some of the other points that you have brought up, I can see the
advantages over CVS, but CVSNT has seemed to pick up the slack on its own.
It now supports changesets which is definitely very valuable and I believe
it does deltas of bin files (although not entirely sure).
With respect to the repository, I am a little confused about a few things.
I know that SVN was originally designed to run off a db. However, I know it
now does flat files as well. Is the flat file structure not akin to a CVS
repository? Has there been any further progress or development to support
DBs other than BDB? Do you know if there is a particular reason why BDB was
chosen vs something like MySQL?
One of my concerns is related to revisioning; if I am working in a
specific file, and want to see a previous version of that file, does that
require the client to download the entire code repository of a previous
version? In CVS, since files are versioned independently, I can easily see
the state of any one file throughout its history, and retreive a particular
revision for that one file and stick with it (ie: sticky tags). Does that
concept still hold true for svn?
I realize that SVN was originally designed to be the next-gen CVS. However,
from some of the feedback I've read, it hasn't lived up to its full promise,
and hence am looking to see if it is worth the move. Like I said, the fact
that so much of the OSS has adopted svn as the new standard is giving me a
lot of reason to follow suite.
One of the things that drives me utterly nuts with CVS is the lack of file
renaming support. In Java and webapps, especially, this is incredibly
critical as when you want to change a class name, you have to change the
file name as well. In CVS, it is a royal pain, and you typically end up
losing the history (unless you go trolling thru the Attic). Does SVN make
that less painful? Am I able to easily rename/relocate files within a
project/branch without hassle? Will SVN's merge tools pick up the file name
change between commits or branches and help me merge changes easily?
Thanks for all the help!
Eric
"Michael P. Reilly" <arcege_at_gmail.com> wrote in message
news:7e5ba9220909091157r79f3abcdw9fde1b2c8924cd23_at_mail.gmail.com...
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=2393326
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-10 17:52:24 CEST