During my early years of development I only knew of one way locking was done by source control systems (SCM), and that was pessimistic locking. Before modifying a source file you have to ‘lock’ it, so that nobody else can modify it at the same time (hence the pessimism). I had heard about optimistic locking, but purely from an academic standpoint and that approach did not seem very practical to me. One day I had to use an optimistic based source control system: Subversion (SVN). Although at first the change of paradigm was not smooth, nowadays I have been converted into an optimist. This blog is about my experiences transitioning from pessimist to optimist and why I now prefer optimistic locking.

Disclaimers:

1. For the context of this blog I will refer specifically to Microsoft Visual SourceSafe (VSS) as the pessimistic SCM and SVN as the optimistic locking system. VSS is going out of support this year and has been replaced by Microsoft Team Foundation Server (TFS).
2. SVN lets you lock files and several ‘pessimistic’ systems will let you concurrently modify files and merge later. For this blog, I am generalizing to the most commonly used method on each system, i.e. no locking for SVN.
3. There are more features and capabilities that comprise a source control system beyond its locking mechanism. This blog focuses primarily on the differences created by the locking mechanism used on each system.

What do you mean there is no ‘check out’?

Let’s establish some key terminology differences. In VSS you have ‘check out’ and ‘check in’. In SVN you have ’update’ and ‘commit’. Commit is almost equivalent to ‘check in’. There is not a ’check out’ command in SVN. You can modify any source code file without asking for permission or having to reserve the file. In fact you do not even need to update (get the latest version) of the code before making changes. On a pessimistic source control system when you check out a file, it automatically gets the latest version from the repository. In SVN, an update occurs when you attempt to commit your changes. Checking out a file from VSS or similar system can be frustrating when you have a slow network connection since you have to wait for the file to be checked out before you can modify it.

Merging changes is not as bad as it sounds

So I don’t have to lock files before modifying them, how do I know somebody is not working on the same file? You don’t, and chances are that somebody else is. And the only way to find out is by checking in your code or updating periodically to get other developers’ changes.

Ok, so somebody else did modify the same file, what do I do know? I don’t want to lose my changes! You can either do a ‘diff’, ‘update’ or ‘commit’. I prefer doing a diff first which will let me know in advanced which files changed. Update and commit behave similarly in that if the file changed in the repository, SVN will attempt to merge the changes automatically. If there were changes that SVN cannot merge automatically (e.g. changes within the same lines of code), then it will generate a ‘merge conflict’. When you are new to SVN, merge conflicts will appear daunting. SVN will modify the file with conflict markers and create 3 new files: file.mine, file.r2582, file.r2586. The .mine is a copy of your modified file (without the conflict markers), the other two correspond to the latest revision on the repository (HEAD version), and the last version you had checked out.

The merge conflict markers in your file look intimidating and are somewhat hard to read:

In the example above, you and somebody else were working on the same line of code. You both arrived to code that is equivalent just with a different style and SVN has no clue as to which version to keep. It is your call to decide which change or combination of changes to keep. Once you have made up your mind, you can remove the conflict markers and keep the line of code you want. This approach is prone to error because you could end up deleting more lines than you should or unintentionally leave conflict marker characters (been there, done that). Fortunately most SVN tools make this easier by providing a visual view of the ‘merge’.

From my own personal experience, I’ve found that merge conflicts occur less frequently than you would expect.

Oh no, I forgot to check in my code… before going on vacation!

How many times did you or somebody else forget to check in files before leaving work or worse yet, before going on vacation? If you are using a pessimistic locking system, you immediately want to start cursing at that person. In the optimistic world, this not a problem at all: worst case you may have to merge your changes when you return from vacation. This seems to be a more just system: the developer who forgets to check in code gets penalized and not your teammates.

What are these ugly .svn hidden folders?

When you first get a project from a SVN repository it will create a hidden .svn folder for each folder retrieved. Each of these folders contains subfolders and a set of cryptic files on each of its subfolders. The first time I saw these folders created, I immediately wanted to delete them. I quickly learned that you must never alter the contents of these folders. These hidden files and folders is what allow SVN to keep track of which files have changed locally.

One of the beauties of SVN is that you can ‘revert’ to the last version retrieved without contacting the repository. This is particularly useful if you ever need to work ‘offline’. These files also make subversion ‘feel’ fast when committing changes, since it already knows which files were updated, deleted or created locally. Every SVN plugin, client or tool will automatically exclude these folders from the source code. The problem arises when you need to upload them or copy them somewhere outside a subversion-aware tool. An easy way to export a copy of your source code without these folders is by executing the SVN export command.

Tooling support is important

SVN is command line driven. You do not need a plugin or GUI client to use subversion, all you need is the SVN client. Having said this, it is extremely helpful to have IDE integration and/or Windows shell integration. The good news is that there is a plugin out there for almost every IDE you can think of. For instance, AnkhSNV integrates really well with Visual Studio .NET. If you prefer to interact with the SVN repository outside your IDE, TortoiseSVN provides shell integration for Windows Explorer.

You typically don’t get to choose a source control system

At customer engagements, it is rare that I get to pick my own source control system. Because of this, I have had to work with many different source control systems: VSS, VSTS, CVS, SVN, StarTeam, ClearCase, Harvest, etc. From my experience, SVN is the one that best supports concurrent changes and merging of source files. If I have the option to choose or recommend a source control system, SVN is my first choice.

Be Sociable, Share!

•