Category Archives: Version Control Systems

Distributed Agile Webinar Feb 16

Mail from Steve Berczuk:

I’ll be participating in a Webinar hosted by WanDisco on Feb 16:

Free Webinar: Make Subversion Agile in a Distributed Development Environment

I’ll be speaking for the first half about agile and SCM, and a bit
about the challenges of distributed development, and someone from
WanDiso will be speaking the second half about tooling to make
subversion work well for agile teams in a distributed environment,
followed by a question and answer period.

Internally I’m suppressing comments about making Subversion agile with a ball peen hammer. I’d still choose SVN over CVS, SCCS, RCS and a bunch of Enterprise tools.

Versioning Derivative Artifacts

Versioning Derivative ArtifactsVersioning the wrong things is an antipattern of software configuration management. A couple of years ago I wrote a blog post about the evil of using a version control as a filesystem, in response to a team member checking in ~250mb of binary crap into our fragile little Perforce server.

Claudio Bezerra commented, and asked:

I saw that one visitor, Fabrizio Dutra, mentioned that versioning derivative files is a bad practice and I agree. However not everyone at my office agrees. Do you know of books or articles that confirm this assumption?

I don’t have a reference for you Claudio, but I can tell you that it’s just plain wrong. My take on it is that it’s fear driving people to want to version generated artifacts. If you perceive a risk that you may not be able to re-generate something, then it’s tempting to want to version it.

My issue with doing that is that you end up with another risk – it can effect your ability to make changes. Your own project (or downstream projects) can treat those artifacts as a something canonical, and lose all reference to the source files that created them. Also, if you do have trouble re-generating them, then it’s all too easy to fall back on your versioned artifacts. Will you still be using them in 2015?

If you version all the source files accurately, and practice Continuous Integration, you can make sure that you’re always in a position to generate any project artifact. Don’t forget to ensure that some of these critical projects get built from time to time. It’s a useful feature for a Continuous Integration server to be able to ‘tickle’ a project if it hasn’t been built for a month or so: environments change, licenses expire, and software rots.

Photo thanks to KevinPoh


Branching: do it like this and nobody gets hurt

Branching: do it like this and nobody gets hurt
It’s a very simple pattern. Make a Continuous Integration build for the trunk and the release branches. Most projects don’t need anything more clever than this.

Your version control system is not a file system

If you find yourself needing to check binary files into your Version Control System, something isn’t right. Your VCS is optimised for tracking changes to source files. When you have multiple revisions of a source file, the VCS has stored the original file and the changes between revisions. This is good.

When you check in a binary, it doesn’t really do that. Most systems just keep a separate copy of the binary for each revision. So if you store 10 revisions of a 100 megabyte file, you can kiss a gigabyte goodbye. You might argue that disks are cheap. Unfortunately the cost of storage isn’t the issue. It’s the downtime to upgrade the server, it’s the admin overhead and risk of moving all of your data to a new disk. Sure you can do it.

Or you could stop using your VCS as the most expensive file system in your organisation.

(image from D. Meutia’s photostream)

Update: I wrote this in response to a contractor putting a 325mb file into my previous employer’s Perforce repository. I should qualify some of the statements in the post – for example there’s every reason to put small binary files in as part of your app. I think most people choose to check in binary dependencies into their projects rather than take the Maven/Ivy route.

Subversion 1.5 has been released

With shiny new features. The nicest feature for me is Merge Tracking, which means you don’t have to manually keep track of what’s been merged from your release branches to your trunk.

Link (via

Git – coming to a Windows computer near you?

Mono founder Miguel de Icaza just twittered about a Google Summer of Code project called Git# – implemented in C#, with no platform dependencies. Git is a powerful Distributed Version Control system that came from Linus Torvalds. While you can convince it to run on Windows, it has dependencies on the Unix toolchain. This project could change all that.

How to find out what files aren’t added in your Perforce client

How to find out what files aren’t added in your Perforce client(image taken from jparise’s photstream)

I’ve first used Perforce in 2002. At the time we were using another product. Perforce was about 10 times as fast and 10 times less likely to make me want to storm into the comms room, rip the source code server out the rack and drop it off the fire escape into the street. It was also atomic.

A lot has changed in the intervening years. Subversion has come of age, distributed version control has become the next new thing, and I don’t have access to the comms room any more. Oh, and I’m using Perforce again. One thing I miss is Subversion’s ability to tell you the status of all files in the sandbox (which is roughly equivalent to a P4 client), including unversioned ones:

graham-tackleys-mac-mini:~/Documents/workspace/playpen jsimpson$ svn st
? a.html

In this instance, you can tell that ‘a.html’ and ‘’ aren’t versioned in Subversion because they have a status of ‘?’.

What do you do for the Perforce command line client? If you’re a Windows user, you can do this:

dir /s/b/a-d | p4 -x- have > nul: 2>missing.txt

The part to the left of the pipe (the ‘|’ symbol) gives you a list of all the file in your current working directory. The part to the right of the pipe queries perforce to see if the files are in the repository. Any files that are in the repository get binned, whereas any files that aren’t get written to the missing.txt file with the dreaded Perforce error message: file(s) not on client.

Unix users can try this one:

find . -type f | p4 -x- have > /dev/null 2>missing.txt

This valuable snippet comes from Laura Wingerd’s definitive work on Perforce. Is there another Perforce one-liner that you can’t live without? Let us know!