Related link: http://subversion.tigris.org/
I finally decided to take a real look at
Subversion. This month’s Chicago Perl Mongers meeting is going to be using some source control set up by Ask and Robert at perl.org, and they’re using all Subversion. So I went to Borders, bought Version Control With Subversion (after reading through lots of the free online version), and I’ve been reading through it ever since.
I never realized what I was missing. Articles like Top 10 Subversion Tips For CVS Users talk about how to switch, but less about why.
So far, here’s what I’ve found in Subversion that has been crucially missing from CVS:
- Local versions of everything you do
If you want to cvs diff, you have to be able to connect to your repository. No net connection, no diffing. Subversion stores local pristine copies of what you’re working on, so svn diff will work just fine. Want to start over? svn revert works unconnected, too.
- Symbolic names of revisions
HEAD is the name of the tip of the trunk in CVS, but I’ve always wanted to be able to say “-r-1″ like I could way back when in PVCS days. With CVS, I have to do a cvs log on what I’m editing, and then subtract one. That’s no fun. With Subversion, I can say svn diff -r PREV.
- Real status reporting
In CVS, the only way you can see if something on the server is newer is to cvs update and hope that whatever comes down doesn’t cause any conflicts. With the svn status command, I get real status, so I can see if there are conflicts BEFORE I do an update.
- Atomic commits
If I try to commit in Subversion, but one of the files has a conflict, or is out-of-date, none of the files commits. In CVS, you’ve got a half-commited set of files that you have to fix RIGHT NOW.
- Helpful handling of merge conflicts
In CVS, if there are conflicts, you get conflict markers in your file. In Subversion, you get conflict markers, PLUS a copy of your original, pre-conflict file, PLUS the version that came down from the server, PLUS the version that you were originally editing. Then, you must explicitly svn resolve filename.txt to tell Subversion that you’ve fixed the problem. No more accidentally commiting back into CVS with conflict markers still there.
The one feature that everyone loves, versioning of directories as well as files, is nice, too, but I’ve never had a real need for it. But if it makes you happy, there’s another reason, too.
Now can someone explain to me why projects at tigris.org use CVS as their version control system?