I've been using Subversion for about a month now and I must say after suffering through CVS for years its lovely. The tipping point for me was when I could install it from the stable branch of fink on OS X.
It does just what its designed to do, its a replacement for CVS. After wrapping my head around the few architectural differences I'm completely comfortable with it. Its fixed the stupid CVS problems. Files and directories can be renamed while preserving history. Branching is simpler. You can turn off $Revison$ munging on a per-file basis. The documentation is much better, each command has its own help page (svn help My advice for CVS users switching to SVN: Read Appendix A of the SVN book first. This lays out the major differences between Subversion and CVS. Also, jump directly to version 1.1.1 and use the new FSFS repository type. A lot of the problems you might have heard about SVN stem from the old Berkeley DB format.
What's missing? XEmacs vc-mode support. A few little interface nits (svn mkdir -p, svn tag). Its still a bit slower than CVS.
I'm moving my CPAN modules off CVS and onto my SVN repository as I work on them. You don't need to have Apache2 around to use Subversion, just for the webdav stuff (though Apache2 and mod_perl 2 are nearly mature.) You can set up svnserve (ie. svn: urls) which is the most efficient, its analogous to pserver, with less suck and more security. You can also use svn over ssh ( svn+ssh:) like CVS does.
There's also a few CVSWeb like things out there. WebSVN is one. Kinda ugly, though that's a totally stock installation. At least you can get tarballs out of it. SVN::Web is another.
Personally I use svnserve over an ssh tunnel. Helps to get around stupid coffeehouse firewall rules.
They're just copies. That's it. You're all but literally making a copy of the source tree (they do internal voodoo to make it efficient). However, I have found it quite annoying not having explicit branching and tag commands.
I haven't used branches in SVN yet and I avoided them in CVS. But I did use tags. The thing to realize about tagging is you don't really need it anymore. Which brings me to my next point...
The change in the way revision numbers work is a good thing. Think of it as a project-wide snapshot number. Put another way, a tag for every revision. More to the point, now you know that revision #1234 of Foo.pm goes with revision #1234 of Bar.pm goes with revision #1234 of every other file in the repository.
Tags are no longer terribly important, you can recreate old repository snapshots without them. They're now just... tags. Names for revisions. Instead of bothering to tag revisions now I just stick a "Version 1.xx" in the log of the last revision before release. Usually adding a timestamp to the Changes file.
This also means that since every file has the same revision you can use $Revision$ as a project-wide $VERSION in all your It would be nice if I could do something simple like "svn tag " in my module release script, but its no longer critical for reproducing history as it was in CVS. This also means that since every file has the same revision you can use $Revision$ as a project-wide $VERSION in all your I'm presuming that's if you want version numbers of the form 1.49 and so far haven't moved up to 2.0. What do you do if you want to call a release of your module 2.0? Also, jump directly to version 1.1.1 and use the new FSFS repository type. A lot of the problems you might have heard about SVN stem from the old Berkeley DB format. I'm not sure who to directly credit for this addition, but I do not that back in the ancient, ancient days of Subversion, before most people even knew it existed, Chip Salzenberg took at look at the project and decreed that it needed to be modified to work with flat files. Unfortunately about that time Eric Raymond showed up and dragged the list into a flame war about Perl (the Subversion people were NOT happy about this). I think Chip pretty much disappeared, and I presume someone else ultimately made this addition, but Chip was the early visionary proclaiming it should be done.
vc mode
rooneg on 2004-12-21T13:27:54
Actually, there is already vc mode support, it probably isn't in the version of emacs you're using though. If you're using a fairely recent GNU emacs you can grab vc-svn.el from the Subversion tarball and you're all set. XEmacs users are out of luck for the time being though.
Keep us updated
jk2addict on 2004-12-21T14:29:08
Keep us updated on your thoughts and usage issues. I recently got turned on to the idea of converting to SVN after being exposed to is in the modperl/Apache::Test dev lists.
I like the web interface a lot better and getting source through a proxy via http:https rulez, but having a copy of Apache2 around just for it seems like a pain, altough I hear CVSWeb groks SVN now too.
I still can't get my brain to accept how tagging and branching works without a branch/tag command.
Re:Keep us updated
schwern on 2004-12-22T04:34:02
Re:Keep us updated
jk2addict on 2004-12-23T01:14:21
OK, you've put it another way that makes sense [to me]. I'm installing it now on my dev box.
I took a look at your WebSVN. Is it me, or is it slooooooooow?
Thanks,
-=Chris
Slow slow slow
schwern on 2004-12-23T20:30:17
Its a very slow machine.
Re:Keep us updated
jdavidb on 2005-01-04T20:53:15
Great on Windows too
jplindstrom on 2004-12-21T17:45:40
On Windows, the integrated Explorer interface is awesome!
Screen-shot The small icons on the files and folders indicate change status.
One thing that sucks though; once when I renamed a class and had to move a directory with it's contents, that corrupted the SVN database somehow. That was a while ago, so it may be fixed by now. Or it may be the GUI component using SVN the wrong way.
Thank Chip
jdavidb on 2005-01-04T21:01:26
