As I have some experience with CVS and svn, I have to add a few bits :).
While it is difficult to compare svn to the distributed systems around, if the
question comes up, whether it is a good idea to migrate from CVS to svn,
then my answer is a very strong YES. At my work, we are using CVS for
most version controlling tasks and over the last year we have turned to
using svn for new projects and converted some of the older projects to svn
too. I have made only positive experiences with this migration.
For the casual user, svn is just a drop-in replacement for CVS, as the
update/commit commands work just like expected. The expert CVS user
probably will need some time to adjust to the changes in concept, notably that
branches and tags both are just copies, but after getting familiar
with it, the svn
way is more clear and robust.
On 5/5/07, Brian Downing <bdowning@...> wrote:
> My biggest beef with SVN is, frankly, the branching model. Simulating
> branched history by copies screams "mind-numbingly wrong!" to me in so
> many ways---even to the point where I find I prefer the (also hideous)
> branching of CVS to it.
I would be interested in which way this seems wrong to you?
> Specifically, some problems I've had in my rather minimal use of SVN:
> (although I admit most of these are probably ignorance.)
> a) How the heck do I find out what the branch point of a branch is?
> Even the stupid CVS trick (tagging the branch point) doesn't help,
> because a tag is just another copy.
svn log --stop-on-copy will list the history of the branch till the branching
point (where it was copied from e.g. trunk)
> b) Being able to delete a branch makes me queasy. I understand it's
> just deleting it from the current view of history, and it nicely (?)
> solves the nasty problem of wanting a branch named "foo" that's
> completely different from the branch you had named "foo" three years
> ago, but I've not found a nice way to go back and view the branch
> with the popular browser tools available without randomly guessing
> at which revision it might have existed.
Looking at the history of the "branches" directory should reveal all branching
and deleting operations.
> c) The usual merge stupidities, shared with CVS, except I think CVS
> might actually have more information available about the structure of
What do you mean by "the usual stupidities"? Conflict handling in svn has
the one advantage as it keeps the files before/after merging around so you
have more information about where the problems come from.
What currently is a bit more work in svn is, that you have to find out yourself
what versions to merge (from where to where the branch goes). The good
news is, that automatic merge tracking is a planned feature, hopefully released
later this year. And as you can merge the differences of any two versions of any
point in the repository, merging is useful beyond bringing branches
back on trunk.
A favourite example is, how to undo a change to trunk. Assume between
rev 4 and 5
something has committed to trunk that one wants to go away - the
solution is to merge
the difference between revision 5 and 4 (that is exactly the reverse of the diff
between 4 and 5) back on the trunk.
> d) It seems to me that SVN (or perhaps Tortoise/SVN) makes the operation
> of copying a branch to trunk without a merge a little bit too easy.
> We've had developers at work kill useful changes without knowing
> about it until it turned up weeks later.
The only things you might be able to really kill are uncommitted changes in your
workarea. Other than that, all changes are properly tracked by svn so you can
always revert them in a clean way. So in my experience it is rather harder to do
permanent damage in svn than in cvs.
To comment on some previous posters points:
- the binary file handling is one of the major improvements of svn vs.
cvs. It does
store diffs of binary files (saves a lot of space) and does not change
the file properties suggest so (and they don't by default).
- overall working speed is typically better than with CVS, but as svn
allows for a
variety of different server setup options, there might be some
(if it is served via an overloaded webserver, svn isn't really to
blame for it...)
- Wedging of the repository is indeed tied to the berkely db. But
since quite a while
repositories can be stored in the FSFS format, which cannot wedge, so
I do not know
why one might still use the berkeley db for repository storage.
- with the workarea, it is possible to get into a state where svn
refuses to commit, and
usually it has a very good reason to do so. For example, if there is a
conflict, svn will
not commit it, until you explicitly issue the "svn resolved" command -
I have seen too
many CVS repositories where people have happily commited unresolved commits...
- space usage: this is indeed a point, where svn has an additional
cost. All workareas
do contain a hidden copy of the checked out/commited state. This costs
disk space (which usually is quite cheap), but on the other side
reduces the network
bandwidth used considerably, as for example "svn diff" does not even need to
access the network.