Developer Drain Brain

December 16, 2009

The significance of “Get Latest”

Filed under: Development — Tags: — rcomian @ 10:15 am

It’s a sad fact that many of us still think of VSS as a form of source control. For a large number of developers, it was indeed our first encounter with that kind of technology, and this experience has massively coloured our view of the landscape in a hundred subtle ways.

The model used by source safe for sharing changes is the lock-edit-commit sequence. When we want to change a file, we lock it, edit it, then send the changes back to the server. On the face of it, it’s a pretty good working model, we saying ‘this is mine’, doing what we like and then when we’re ready to give up control of it, we send it back to the server.

Sharing aside, when you’re working this way, it has an impact on how you view a particular action – “Get Latest”. When your whole work area has been ring-fenced from everyone else, getting latest is a pretty cheap operation. After all, you get all the features and bug-fixes that other people have added, and you know they don’t impact your current work because your relevant files are locked and you know they haven’t been changed. So in this world, get latest basically means, get the stuff that everyone else has done to the rest of the system.

In the real world, we all work with an edit-merge-commit process (or possibly edit-commit-merge if you’re in git). In this model, the significance of getting latest is very different.

When you start work, you get a version of the project onto your machine. You then edit that version and at some point, you’re ready to put the changes back into the project. However, the project has been worked on by other people and is likely not the same as the version you originally coded against. If you punted your changes up to the server, there’s no guarantee that your changes are relevant and don’t conflict with work that others have done.

This is where a ‘get latest’ operation comes in. Your not really saying ‘get the work that everyone else has done’, what your saying is ‘Migrate my changes to the latest version of the project’. Only once you’ve done this can you commit your work. Think of a project as sequential layers of changes applied on top of each other. To make the next layer, you need to apply your changes to the top layer. Realise that each and every layer goes across the entire project, a layer may only change one file, but it’s a whole new version of the code base.

Of course, there’s always a risk in migration. Distributed systems like Git are the only source control that handle this risk properly, but TFS and SVN have their own methods. The risk is that the migration may go wrong and you’ll lose your changes. This risk is highest when there are a lot of complex conflicting changes. This is a risk that you’re saying your willing to take whenever you say ‘Get latest’.

Whilst this is a risk, it’s one we all take every day, just like crossing the road. It’s one of the reasons we say “commit often”, it’s so that the resulting merge isn’t too painful. But if that risk sounds too scary for a particular set of changes, you have 2 options. In TFS you can shelve your changes, in SVN you can branch from your current working copy. Your changes are then safe, and if merging your changes into the latest version fails horribly, you can always discard the changes and go back to the shelveset or branch. Git et al work differently, in that you commit your change as is and then merge them with the latest version of the project as a separate, distinct activity.

But the key thing to take away from this is to reverse the way we often think of “Get latest”. We’re not really getting other peoples work, we’re migrating our changes to the latest version of the project. The difference may seem subtle, but it’s important. For example, it highlights the fact that it’s not really safe to “Get latest” on just the files we’ve edited – it means we’ll have a horrible frankenstein project that’s got some changes from here, some changes from there. It may work for us, and any source control system will let you commit, but it doesn’t reflect the project that we’re actually making our changes to.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: