Mike is currently…

snowboarding in Banff

Pragmatic Version Control Using Subversion

[ subversion book ]

obligatory book plug

[ syndicate ]

rss 2.0 feed for boy meets world

[ contact ]

drop me a line

[ about ]

this is mike mason's weblog

[ eskimoman.net ]

original web pages


Wed, 30 Mar 2005

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Shelving Subversion

My colleague Clinton Begin asked me whether Subversion supports shelving. This is something that the new Visual Studio may have as part of its “Team” features, and is basically a way for a developer to put aside a set of changes come back to them later. Storing shelved changes in your version control tool is pretty sensible—your repository is reliable, backed up, and not liable to disappear if someone pinches your laptop.

So can you do this kind of thing with Subversion? You betcha. Here’s roughly how it would work:

  • Whilst working on adding the new “frobscottle” feature Alice decides she’d like to shelve her current working copy changes. Her project, codenamed “xyzzy,” is checked out from svn://svn.acme.com/xyzzy/trunk.

  • Needing somewhere to store her changes, Alice branches the trunk to create svn://svn.acme.com/xyzzy/shelves/alice/frobscottle.

  • Alice uses the Subversion switch command to switch her working copy from the trunk to the new frobscottle branch. When switching, Subversion preserves any changes you’ve made to the working copy.

  • Alice checks in her working copy. The changes will be safely stored under the shelves directory.

  • Alice switches her working copy back to the trunk and works on something else. In future if she wants the shelved frobscottle changes she can merge from the branch to her trunk working copy, then commit the changes back into the main code line.

There are a few details you’ll need to get right—you may need to create the new branch from an older revision on the trunk rather than from the head—and it’s less pretty than a “shelve” button in a GUI, but it’ll work great and you’ll understand exactly where your changes actually are.

Posted 22:24, 30 Mar 2005.  

Fri, 04 Mar 2005

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Subversion FAQ

Pragmatic Version Control using Subversion launched Tuesday night in Calgary. I went down to a local bookstore and spent a few minutes talking about version control, Subversion, and what the book covered. The audience had a bunch of questions about Subversion and I took this as a really good sign — people are doing their own research and wanted to find out more.

Here’s a few of the questions people are asking about Subversion:

How does Subversion compare to other tools? Is there a feature matrix I can look at to decide what tool to use?

Subversion stacks up really well against CVS, fixing the bugs and fragility of CVS whilst keeping the proven development model. Subversion also adds features like change sets, atomic commit, decent networking performance, and a reliable back end. I’m wary of comparisons that read like a school book report, checking boxes if a tool has a particular feature. Those kinds of comparisons always tend to be biased by the person writing them — if you really want to know whether Subversion is right for you try it out on a small project. If things don’t work out you can try something else, if things do work out you’ll know more about the tool and will be better able to roll it out to larger projects.

I’ve heard that Subversion’s database can become corrupted. That doesn’t sound good!

Subversion 1.0 uses the Berkeley DB for storing your files, and this has been a source of some problems. BDB is very reliable when used properly, but unfortunately it’s quite finicky about permissions on its database files. If you set up a Subversion repository, usually on Unix, and have two different users access the repository, if their umask isn’t quite right they can grab control of those database files. This usually happens when you have more than one access mechanism, say svn+ssh as well as Apache. If BDB can’t write to its files it gets stuck, or “wedged.” People often confuse this with database corruption, which has only happened in a few cases and was traced to hardware problems.

Subversion 1.1 introduced the new “fsfs” back end which doesn’t use Berkeley DB and instead uses plain files on disk. This works much better for people using NFS, for example, and helps avoid some of the permissions problems. Most people can stick with BDB as long as they don’t try to mix network servers for Subversion.

I’ve heard Subversion supports “meta-data.” What’s that?

Using Subversion, you can attach named data to files and directories. Each name defines a property and properties can have textual or binary content. The nifty thing is that properties are version controlled in exactly the same way as files — Subversion tracks how their contents change over time, and can perform merges, deletes, and updates just like file contents. Subversion uses special properties to do stuff like ignoring certain files in a directory or setting the “execute bit” for a file.

Since properties are editable just like file contents, you could write a tool that used them in some special way. An example often given is a system that stores big graphic files — you could store a thumbnail inside a Subversion property for each file, then use that in your system.

Why would someone spend thousands on a commercial tool when they can get Subversion for free?

This is a good question, and one that I think a lot of people are beginning to ask. In the case of a version control tool, it may be that a company is happier using a product for which they can pay for support – if something goes wrong they can call someone and get it fixed. But open-source software is challenging the notion that you must pay for support. Subversion has an extremely active user community and you can often get a response in minutes, for free.

I like Perforce, and I actually think it’s better than Subversion in certain circumstances (usually when your branching has got out of control and you’re in a bit of a mess). But is Perforce several hundred dollars per head better than Subversion? I think probably not.

So what’s in Subversion that’s not in your new book?

This was actually the toughest question I faced during the book launch and I had to think for a long time before answering. I think the book covers 95% of Subversion’s features, and easily covers everything you’ll need when using Subversion on a typical project. I couldn’t cover all the advanced usages of Subversion, but I think having read the book you’ll be able to adapt what’s in there to cover any new situation you face.

The book sticks to the Subversion command line, and only covers GUI tools briefly, so you’ll need to experiment a little to figure out how Tortoise works, for example. I think it’s useful to understand what a GUI is doing “under the hood,” so I don’t see this as a serious omission. The book also doesn’t cover IDE integration because those tools are still evolving rapidly.

It looks like we’ll be doing another print run of the book, so be sure to get a copy of the first printing before we correct the typos!

Posted 01:30, 04 Mar 2005.  

Tue, 01 Mar 2005

This is an archived blog post. I've switched to using WordPress as my blogging software and have not migrated all my old posts. I believe strongly in not letting an old link die, so this page continues to work. Please do visit mikemason.ca/blog to read newer posts.

Finding Bugs Is Easy

…or so say the makers of FindBugs, an open-source bug detector for Java. When I’m asked to improve the code quality on a project often the first thing I do is to search for “obviously” bad code. By this I mean I look for stuff like String construction (you never need this in Java), incorrect use of static (makes testing hard, could be a sign people are using singletons), and a few others.

FindBugs takes this approach a step further using automated detectors that look for dodgy code. They work by scanning the compiled Java bytecode and looking for suspicious patterns. Running this against my current project found a multitude of sins, my favourite being the “looks right but is definitely buggy” covariant equals. Next best is the “database resource not closed” detector, and the “questionable reference comparison” detectory – try manually finding bugs caused by Integer object comparison using == instead of equals()…

FindBugs is has definitely found a place in my toolbox, and I’ll be running it regularly to avoid nasty suprises.

Posted 00:39, 01 Mar 2005.  

Mon Tue Wed Thu Fri Sat Sun

[ tim bacon ]

musings of an xp coach

[ ian bourke ]

enhancing core competencies since 1976

[ martin fowler ]

a cross between a blog and a wiki

[ alan francis ]

agile != good

[ paul hammant ]

part of the problem…

[ darren hobbs ]

the blog formerly known as pushing the envelope

[ mike roberts ]

on life and technology

[ chris stevenson ]


[ joe walnes ]

joe's new jelly

[ rob baillie ]


Powered by Blosxom

Registered plugins: SmartyPants, antispam, bloglinks (v0.2), calendar (v0+6i), pluginfo (v1.0), and userstatus (v0.1)
This work is licensed under a Creative Commons License.