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