Using Working Folders in Version Control

The repository is the official archive of a project's work products. We treat our repository with great respect. In contrast, developer often treat their working folder with very little regard. It exists for the purpose of being abused. The working folder starts out worthless, nothing more than a copy of the repository. If it is destroyed, we have lost nothing, so we run risky experiments which endanger its life. In this excerpt from his online book, "Source Control HOWTO," Eric Sink describes explores common "best practices" for using working folders.

Visual Studio calls it a sandbox. Subversion calls it a working directory. Vault calls it a working folder. By any of these names, a working folder is a directory hierarchy on the developer's client machine with a copy of the contents of a repository folder. The very basic workflow of using source control involves three steps:

Update the working folder so that it exactly matches the latest contents of the repository.

Make some changes to the working folder.

Check-in (or commit) those changes to the repository.

The repository is the official archive of our work. We treat our repository with great respect. We are extremely careful about what gets checked in. We buy backup disks and RAID arrays and air conditioners and whatever it takes to make sure our precious repository is always comfortable and happy.

Best Practice: Don't let Your Working Folder Become too Valuable

Check in your work to the repository as often as you can without breaking the build.

In contrast, we treat our working folder with very little regard. It exists for the purpose of being abused. Our working folder starts out worthless, nothing more than a copy of the repository. If it is destroyed, we have lost nothing, so we run risky experiments which endanger its life. We attempt code changes which we are not sure will ever work. Sometimes the contents of our working folder won't even compile, much less pass the test suite. Sometimes our code changes turn out to be a Really Bad Idea, so we simply discard the entire working folder and get a new one.

But if our code changes turn out to be useful, things change in a very big way. Our working folder suddenly has value. In fact, it is quite precious. The only copy of our most recent efforts is sitting on a crappy, laptop-grade hard disk which gets physically moved four times a day and never gets backed up. The stress of this situation is almost intolerable. We want to get those changes checked in to the repository as quickly as possible.

Once we do, we breathe a sigh of relief. Our working folder has once again become worthless, as it should be.

Hidden State Information

Once again I need to spend some time explaining grungy details of how SCM tools work. I don't want to repeat the apology I used in the last chapter, so the following line of "code" should suffice:

Response.Write(previousChapter.Section["Cars and Clocks"]);

Best Practice: Use Non-Working Folders When you are not Working

SCM tools need this "hidden state information" so it can efficiently keep track of things as you make changes to your working folder. However, sometimes you want to retrieve files from the repository with no plan of making changes to them. For example, if you are retrieving files to make a source tarball, or for the purpose of doing an automated build, you don't really need the hidden state information at all.

Your SCM tool probably has a way to retrieve things "plain," without writing the hidden state information anywhere. I call this a "non-working folder." In Vault, this is done automatically whenever you retrieve files to a destination which is not configured as the working folder, although I sometimes wish we had made this functionality a completely separate command.

Let's suppose I have a brand new working folder. In other words, I started with nothing at all and I retrieved the latest versions from the repository. At this moment, my new working folder is completely in sync with the contents of the repository. But that condition is not likely to

Pages

About the author

TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.