A good source control system is a must for almost all programming projects. For instance:
- You can quickly check which lines across multiple files you’ve changed.
- Revert changes to any previous date.
- Never lose any file again.
- Keep track of why a file was changed, by whom and when.
- Take snap shots of release code versions.
- Manage multiple engineers working on the same code base.
- Automatically combine code from multiple engineers.
- Split code development into various paths then quickly combine at a later date.
Over the years I’ve used many different source control systems – SourceSafe, CVS, Perforce, CodeSafe – but the one I’m most impressed with is the only one I use at home and the one I encourage at work: Subversion.
Subversion is an open source, source control system (and they “eat their own dog food” – explained). It’s available on Linux, Windows and Mac and you can freely download it from their website.
If you used CVS before then you’ll probably understand how it works, but if you are more of a SourceSafe person (I feel for you) then Subversion takes a little explanation. Subversion works like this:
- First you create a “repository”, this will be where all the files are stored, lets call it “TestProj”, you’ll normally create this on your server so that multiple people can access it.
type: svnadmin create your/path/TestProj
- Now locate where you want your own working copy to exist, lets call it “MyTestProj” and “Check Out” TestProj, this simply creates all the files in your repositiory (there isn’t any yet) together with some other files in a folder called “.svn” which holds the admin bits that subversion needs (you’ll see one of them in every subfolder you create).
type: svn file:///your/path/TestProj MyTestProj
- Now create some files, say “TestProj.cpp”, “TestProj.h” and “TestProj.ico” in MyTestProj folder. These currently exist only on your computer so you need to “Add” them to Subversion. This just means you “are going to” add them, subversion won’t do anything until you subsequently “Commit” these changes, at that point you’ll get the opportunity to comment on your changes.
type: svn add TestProj.cpp TestProj.h TestProj.icotype: svn commit --message "Adding first files"
- Now all your files are commiteed and the files are added inside the repository you created. Anyone else doing “Check Out” will see them in their working folder.
You can stick any folder or file in your working copy, and make any changes to the files you wish, nothing will happen to the Repository until you commit. You can “Update” you copy at any time to get everyone else’s changes or “Commit” you’re own changes back – by default there is no locking of files – if you change the same file as someone else then Subversion automatically merges them together –
…take a deep breath if you are a SourceSafe user, this will sound like witch craft…
– in almost all cases code can be automatically added as different lines will have been changed (this was hard for me to believe back when I first used it but believe me it’s clever enough to never cause a problem). On the rare cases (although this depends on project size, user number and frequency of updates) you’ll get a “Conflict” which means you’ve changed the same line someone else has and you’ll have to sort this out yourself before you are allowed to commit your changes.
There’s more information at:
- Their FAQ: http://subversion.tigris.org/faq.html
- And a very thorough online book here: http://svnbook.red-bean.com/
- There’s also the commandline help: svnadmin –help <command> and svn –help <command>
That ends the first Subversion blog, in the future ones I’ll be looking at a folder structure you can use to make your projects easier to manage (see here), some of the client apps that exist to make working with subversion easier and more efficient, backups and a few more bits and pieces.