Output Stream of Consciousness

Link: http://subversion.tigris.org/

No spies or anarchy here, at least in the traditional sense. I'm talking here about a magnificent little version control system, and if you're programming or even maintaining documents, it is a godsend.

For those who don't know what version control systems are, they are relatively simple in concept: they keep revisions of your project files around, and help coordinate multiple people working on the same project. For the revision capability alone, it's worth it. You 'check out' files from the central location, change some, then then 'check in' your changes.

Subversion is by now a quite mature project. It was surprisingly reliable when we first picked it up. Of course, they "eat their own dogfood", that is, they use Subversion to source control Subversion. It's nice to have people relying on their own project to work on their own project; it means that they're in the same boat as the users of their project.

Subversion now does support locking, that is, keeping other people from editing a file while you're working on it. That said, the original and still highly recommended way is to use the copy-modify-merge approach. Basically, you are allowed to edit files at will. If you try to check in your changes, and someone has changed the files in the meantime, it will flag a problem. You ask for an update, and Subversion will either merge the two changes (I have yet to see it make a bad merge), or show that there's a conflict, and give you three files, a "theirs", a "yours", and a "best guess" at what the combination should be, though there will be lines it does not know how to merge in a conflict.

You can rename, delete and move files, and Subversion will still keep a history of them. Subversion also tends not to keep multiple actual copies of the same file around in the repository. So if you "tag" a version (say, for example, you're releasing version 2.5 of your product, so you tag it as 'Release 2.5' so that you can get all the project files at that version if anything should go wrong), it doesn't copy all the files into the tagged copy, it just copies references. This makes Subversion pretty fast in some unusual-to-be-fast-in areas. One feature, "switch", switches you between versions of your code. If the versions aren't really, really far apart, this is surprisingly quick - it only updates the differences on your machine.

There is a Windows Shell Extension that simply is a must have for Subversion, and that is TortoiseSVN. This extension lets you run most every Subversion command from an open file folder, and gives you visual comparison tools and other graphical bits. (I often go into Show Log, pick a revision of the file and go Show Differences to see what changes have been made). Files that you have changed are marked with exclamations, ones that are untouched have green checkmarks. It works pretty intuitively.

Here are a few of my experiences from running Subversion and TortoiseSVN:

If you are using 'hard' directory paths (e.g. C:\Program Files\Bla\Bla), you would be best to figure out how to make everything in your project use relative paths (e.g. ..\..\Bla) instead. With Subversion, you can check out a project into any directory, so if anyone else tries your project code, they will find it broken.

Subversion keeps a second copy of practically every text file in your project. It's in a hidden directory, and otherwise pretty transparent, but be aware it takes up space. This is how Subversion figures out changes, merges, etc.

I'm really behind the copy-modify-merge technique. I really am. If you have worked in a locking system, you may know what I mean. People forgetting to check in, and not being able to check out, can cause severe troubles. I do get occasionally blindsided by forgetting to do an Update before I start working on files, though. It's not so much of a problem for text files (like source code files), but it can be a pain if it's a Word document.

The command-line tools are pretty simple to operate as well. One thing I highly recommend doing: using them to make automatic builds of your product. This way, it can suck out the most recent project files and use them in the build. We use CruiseControl to help out with this, but there are many ways of doing it. Being able to be e-mailed when a change broke the software, or broke other pieces of software, is very, very handy.

It looks like Subversion is catching on in the Web. One of these days, I suspect, SourceForge will start using it on a trial basis - how soon is anyone's guess - and then CVS, the most pervasive but aged open source version control system, may at last start to be phased out.

Comments:

# We're using the original CVS system with a UNIX repository on our Sun servers and PC-CVS for DOS for the various Wintel boxen. It's not flashy by any means, but it does seem to work although I think L2 may have a few things to say about ease of maintaining code branches using it. We did try to use the Windows version but the interface was so incomprehensible we gave up.

Comment by Adam [Visitor] — 09/20/05 @ 09:57

# Don't let L2 see this; he's going to make my life horrible at work as he decides to migrate our code base to a different CVS system.

Comment by Adam [Visitor] — 09/19/05 @ 15:07

# > prevent -u L2 -m viewing -r:will_make_adams_life_difficult

[ERR]Rejected - this computer likes L2

Oh man...

What are you guys running over there, anyhow? We were in the 'fortunate' position of using a free version control system that was causing us pain (everyone had to make an E: drive with a \Development folder, your own devices be damned, the file list took over a minute to come up after a year of using it, etc.). It did break stuff when we moved - no mistake about it - but mostly that was absolute to relative path stuff.

Switching version control systems is best done on a side project. It's great to get all the "oh, *that's* where I should put things" or "*that's* how I merge files" out on a somewhat less than mission critical project.

I'll have to give you a tour of Subversion at some point. It's neat.

Comment by nimble [Member] — 09/19/05 @ 20:43

# Are you using TortoiseCVS for the client end?

If you're using a relatively up-to-date CVS, you'd be in luck. There's actually a Python script for doing the conversion between the two.

So I don't want to rock the boat, but you have a much better migration path than we did, or MS VSS or StarTeam users would :)

Comment by nimble [Member] — 09/20/05 @ 10:19

# It's v1.10 of CVS. The copyright date goes to 1998 so it's a bit stale, but not as bad as it could be. Management here wants to abandon the UNIX systems as they're finding it tought to find people to support them. I'm just rather nervous about moving from a platform and process I know that works and is reliable to a Windows-only shop where stability seems to be job #2 (or lower.) Then there'll be the absolute fun of putting development environments on every desktop, something else they want to do; can you imagine how expensive and hard to maintain that'll be?

Comment by Adam [Visitor] — 09/20/05 @ 10:27

# I understand - we have sparse few alternate-OS machines. I think one's a Fedora box and the other is FreeBSD. Subversion's running on FreeBSD.

Development environments on every desktop, huh? What's that for? If it's for debugging on various environments, then fine, but otherwise, what's the point? Sounds like it might be worth pushing for components to add to the software to help traceability and error reporting to help stave off this need.

...unless they're figuring the sales guys should try their hands at programming too? :)

Comment by nimble [Member] — 09/20/05 @ 11:14

# It sounds as if maangement has decided that since desktops are so powerful these days, they ought to distribute the workload to take advantage; i.e. instead of buying mondo servers for common use, let the client machines take the strain. In addition, as almost all of our customers are on Windows these days, it would make sense to develop and do unit testing on a platform the same as the ultimate destination. There's a definite logic there but I remain unconvinced that it'll work. Perhaps if someone came up with a distributed system of compiling similar to the way the SETI system worked, that'd be good, but I think we'll just be using bog-standard VisualStudio installations. The programmers have been complaining that the debugging tools in Windows just aren't as good as those under UNIX, something I can accept. Unfortunately we've also encountered bugs and behaviour in Visual C++ where certain operations result in compiler stack overruns, or misbehaviour on initialization of variables (where the UNIX compiler gets it right and the MS effort doesn't) which means nasty bugs get past the unit testing and land on my plate when I do the Windows testing before it gets shipped to the client.

Anyway, as you can tell, I have mixed feelings on this one. I can see benefits and problems and I don't know whether one out weighs the other.

Comment by Adam [Visitor] — 09/20/05 @ 11:39