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?
CVS status
cvs -n updateshows you what will happen when you update, but doesn't do it.Eclipse
Eclipse is why I use CVS, not subversion -- eclipse Subversion support is poor compared to its CVS support.
Eclipse
Amen, using CVS through Eclipse is a great relief, its CVS integration is almost worth the whole IDE (thank God for the merging tool).
But. That's only a workaround (albeit really well done) and you still have some of CVS's limitations: atomic commits are my major issue, but also pristine local versions would have been useful a couple times (this is different than E's amazing local history).
Subversion's plugin is obviously young and incomplete, if it received the same amount of love as CVS's we'd probably have an even better toy.
tigris.org uses CVS and Subversion
Some projects at tigris.org use CVS for the source code of the project home (i.e., the code to produce HTML) while keeping the actual project code in Subversion. Some might keep everything on CVS. It depends on the project legacy. One example is the Subversion project itself, which is hosted on Subversion itself.
Just FYI
About "Local versions of everything" if you use GNU Emacs when editing the file he backup old file automatically as well and you can diff unconnected.
As do most text editors,
but for nontrivial rollback situations, as when you have closed and reopened a file, or when there are multifile dependencies that must be rolled back atomically, it isn't much help.
Heard of darcs?
darcs.
Every feature list above is supported. Resolving merge conflict is not only helpful, but natural. Darcs is small (minimum dependencies), and beautiful (theory of patches).
CVS status
Yes, I do that all the time, was about to mention it.
As to local repositories, that's something I've only very rarely cared about -- only when I do not HAVE an Internet connection -- and I worry about potential greater conflicts from having my local repository out of date in such cases.
Those additional symbolic names would be nice, but not a reason to switch.
Atomic commits is nice, although again, something I rarely need. If a commit fails, I fix the problem and recommit that one file, which has never bothered me before.
CVS gives you two copies, your original pre-conflict and the new one. This has always seemed sufficient to me.
None of the reasons given seem to me to justify the pain in moving to a completely new system, which is not just relearning a new system and moving the source over (esp. since I don't control the servers, so I'd need to be political as well), but rewriting dozens of scripts, and finding new clients to use (I use BBEdit and MacCvsX regularly). Plus, there's my coworkers and all their similar pain. Plus, many of my users use anonymous CVS, so I need to cause them some of the same pain.
CVS status
. I'm aware of it, and it's a disaster waiting to happen.I really don't like the idea of using
I'm disconnected with some regularity, so I like that. I also use CVS for more than code: Anything I write, it's in CVS.
Nobody's begrudging you sticking with CVS. For what I need, both on a personal level and in my department, it's going to be worth the time and effort.
Just FYI
A backup file? Dude, you must be kidding! ;)
CVS status
Why is `cvs -n update` a "disaster waiting to happen"?
CVS status
Because if you forget the -n, you do a full-blown update that you never intended to have happen.