SVN as a synonym) and CVS. He enlightened me on the advantages of the
former.
The strongest argument I find in favor of Subversion is the concept of
revisions. In fact, some time ago, while working on a project that
uses CVS, I came accross the need to determine which files I had just
committed. Turns out that, in CVS, there is no easy way to do that:
files are versioned separately. Conversely, in SVN, a global revision
number is incremented with each commit. In this way, it is possible to
know which files were commited together, by querying the SVN system
about what happened in a specific revision.
Moreover, should the need to revert the state to some point in the
past arise, this would translate in SVN to just replacing the files
with an old revision, and all files would be consistent and work with
the others appropriately With CVS, there would have to exist a
previously made tag if a set of files must be in accordance,which is
usually the case.
From what I explained above, it can be concluded that many of the
cases in which tags are needed if CVS is used, are eliminated by the
use of SVN, thus simplifying administration. SVN is also quicker at
branching and tagging than its predecessor.
There's another issue: that of renaming files. In SVN, as opposed to
CVS, there is true file renaming, which preserves the whole history of
the file. In CVS, the normal way of renaming consists of a delete plus
an add.
Migrating from CVS to SVN can be done in a very short time, and a true
SVN repository results from the process. The migration implies looking
at the user and time of commits to group files together as tough they
were actually committed using Subversion.
