Anti-Practice: Reserving Files

Originally published 20 Aug 2006

Here is the first blog in a series discussing some obsolete practices and just plain annoyances regarding builds and source code management. The context is an agile development environment following the best practices of continuous integration (CI) and collective code ownership. The team is of medium to large size, possibly distributed, and working different hours, possibly in different time zones.

The first obsolete practice is reserving (locking) a file by default when checking out the file. (I’m using ClearCase terms here). This is like pessimistic locking in the database world. The thought is, “I’m going to reserve this so that no one else will affect me. I’ll make my changes, then check in. If anybody else wants to modify the same file, they’ll have to wait for me to finish, then deal with merging in their changes.” That doesn’t sound like collective code ownership to me. Sharing the code base means sometimes having to deal with merge issues.

Reserving files prohibits others who are ready to check in. In the worst case, suppose a person with reserved files leaves for the day (or for vacation). Others are likely working different hours, so what do they do? They try to get in touch with you to see what’s up. They can’t get a hold of you, but they are ready to check in and move on. So after some time not hearing from you, do they unreserve the files? In some stricter environments, what if they don’t have rights? What if they can’t get in touch with the select few that have rights to unreserve files? (By the way, if you do unreserve a file, make sure you tell the person who reserved it that you did that.) The point is reserving files slows down the team.

There are of course exceptions. An important change or a change that has a big impact to the system might merit an early reserve on a check out. In this blog, I’m talking about reserving files by default.

The biggest positive of reserving early is finding out that somebody else is working on the same file. For example, I try to check out a file and reserve it right away and find that I can’t because Joe’s got the file reserved. Depending on the circumstances, I may want to know exactly what Joe’s doing. I’m not familiar with another way of getting this notification as easily without getting spammed by unwanted notifications. In other words, I might want to know, upon check out of a file, whom else has the file checked out.  For me, this advantage doesn't outweigh the disadvantages mentioned above.


Next time I’ll talk about an annoyance or two that occurs when a build breaks.