Related link: http://subversion.tigris.org/
I don’t have a ton of complaints about RCS (which I started using about 14 years ago) or CVS, though I am sure others have more. My one fog-minded problem I had with CVS was configuration — just getting it to work as expected — which might have just been a documentation or operator (that’s me) problem. It’s been awhile, so I don’t remember what sources I was using, but I got frustrated and just created my own silly backup system with a script and ZIP. In the last few weeks, though, I stumbled on Subversion. I downloaded and installed it, and so far I am liking it. Actually, I am liking it a lot.
Subversion has really good documentation, which made the set up easy and sort of fun. I downloaded the Win32 version of Subversion to my Windows XP box (Jostein Anderson’s installer version). (Subversion also has builds for Redhat, Debian, SUSE, Mandrake, FreeBSD, pkgsrc, and Mac OS X.) Once installed, Subversion was available at the command prompt (there’s a UI version for Windows, too), and I was able to set up a repository and start checking things in with just a handful of commands.
Here is a cheat sheet for using Subversion on Windows on the command line (probably works on other platforms if you just change the file paths to match your platform).
Create a repository:
svnadmin create c:/repository
Get help on any command:
svn help import svn help checkout svn help ci
Import a directory (c:/Stories) to the repository:
svn import Stories file:///c:/repository/Stories -m "initial import"
Checkout (co) the directory (I moved the original directory out of the way first, just to keep things straight in my own mind):
svn checkout file:///c:/repository/Stories Stories
The Stories has a file called genx.html. Edit. Edit. Edit. Commit (ci):
svn ci genx.html -m "Incremental backup"
Look at the log in XML:
svn log genx.html --xml
Result:
<?xml version="1.0" encoding="utf-8"?> <log> <logentry revision="6"> <author>mike</author> <date>2004-05-10T23:24:56.959208Z</date> <msg>Incremental backup</msg> </logentry> <logentry revision="5"> <author>mike</author> <date>2004-05-10T21:49:15.263054Z</date> <msg>Incremental changes</msg> </logentry> <logentry revision="4"> <author>mike</author> <date>2004-05-10T21:36:39.796747Z</date> <msg>Incremental changes</msg> </logentry> <logentry revision="3"> <author>mike</author> <date>2004-05-07T21:20:05.425290Z</date> <msg>Added to set up section</msg> </logentry> <logentry revision="1"> <author>mike</author> <date>2004-05-07T19:27:47.276308Z</date> <msg>Initial import</msg> </logentry> </log>
If you are not entirely tickled with CVS, try Subversion. It’s clean, it runs on lots of platforms, it’s nicely documented, and it’s a pleasure to use. There is promise of cool new features (such as HTTP WebDAV/DeltaV repositories on Apache servers), and from what I’ve seen, I think the Subversion folks will deliver.
Will you try Subversion, or is it too much of a hassle to move away from CVS?


TortoiseSVN
If you're running under windows, TortoiseSVN is well worth checking out. It gives you subversion integration with the windows explorer. Check out, update, diff, commit all from a familiar tool.
-Dom
new features? not really that new
There is promise of cool new features (such as HTTP WebDAV/DeltaV repositories on Apache servers)
There is the promise of other new features, but these ones you listed are already there. They've had DAV support through Apache for a long time. As long as I've used Subversion, in fact. Perhaps 2 years or more...
Before you paint yourself into a corner...
Note that if you import your projects directly into a top level directory of your repository like that you're going to have trouble later on if you want to create branches or tags.
The common practice is to create a directory for each project that contains 'trunk', 'tags', and 'branches' directories. The main development for a project is done in the 'trunk' directory (and that's where you'd normally import your project into), and to create branches or tags you'd make a copy of the trunk in the 'branches ' or 'tags' directories.
Before you paint yourself into a corner...
Note that if you import your projects directly into a top level directory of your repository like that you're going to have trouble later on if you want to create branches or tags.
You won't really get much trouble later on. You can just move your stuff into the appropriate directories when you need to. One of the many advantages of SVN is that we keep our version history in this case :-)
Converting from VSS
My company is considering to take the plunge now... are there are good tools to convert from VSS (visual Source Safe) into Subversion?
I've used it (svn) on little home projects, but never had to ponder massive imports.
Converting from VSS
I'm afraid there isn't yet a good way to convert VSS to subversion. I know of two projects that are trying, however:
* https://chidb01.tallan.com/vss2svn
* http://svn.clkao.org/revml/
The former looks promising, and might actually work on simple databases, but has holes (albeit well-documented holes).
TortoiseSVN
I'd go further and say that TortoiseSVN is the only windows client that is ready for Prime Time now.
CVS Installation
Installation of CVS on a Unix system is not an issue. In fact, most Unix distributions have it pre-installed, and Mac OS X includes it as well on its Developer Tools CD. I guess the problems you encountered were in Windows. There has never been a distribution for Windows by cvshome.org. There is a port of CVS by cvsnt.org but it does not share the codebase from cvshome.org. On Windows an effective way is to run the CVS server on a Unix layer, such as Microsoft Services for Unix.
On the other hand, Subversion was developed from the outset to build and run on Unix and Windows. This is surely an advantage when considering using an open source versioning system in corporations, since many have Windows as the main development desktop. More generally, Windows should not be ignored by open source projects, simply because of its large user base. Also, developing for multiple operating systems arguably results in cleaner designs, with more attention to modularizing system dependencies.
TortoiseSVN
TortoiseSVN will also integrate into Salamander 2.5.
Just in case ...
Franz-Josef