logically grouped together even as they are waiting to be checked in.)
The "Change Set Comment" textbox offers a place for me to type an explanation of what I changed and why I did it. Please note that this textbox has a scrollbar, encouraging you to type as much text as necessary to give a full explanation of the problem. In my opinion, checkin comments are more important than the comments in the actual code.
When I click OK, all of the selected items will be sent to the server to be committed to the repository. Since Vault supports atomic checkin transactions, I know that my changes will succeed or fail as a united group. It is not possible for the repository to end up in a state where only some of these changes made it.
Remember the discussion in the last edition about binary file deltas? This same technology is also used for checkin operations. When Vault sends a modified version of a file up to the server, it actually sends only the bytes which have changed, using the same VCDiff format which is used to make repository storage more efficient.
The reason this is possible is because it has kept a copy of the baseline file in the hidden state information. The Vault client simply runs the VCDiff algorithm to construct the difference between this baseline file and the current working file. So in the case of my running example, the Vault client will send three pieces of information:
The binary delta. Since the pending change set pane shows that my working file is 40 bytes larger than the baseline where I started, the binary delta is going to be somewhere in the vicinity of 40 bytes long, perhaps with a few extra bytes for overhead.
The fact that this binary delta was computed against version 21 of the file. Since version 21 is known and exists on both the client and the server, the SCM server can simply apply the binary delta to its own copy of version 21 to reconstruct an exact copy of the contents of my working file.
The CRC checksum of the original working file. When the server reconstructs its copy of the working file, the CRC will be compared to ensure that nothing was corrupted during transit. The file that is stored in the repository will be exactly the same as the working file. No corruption, no surprises.
Whenever possible, Vault uses binary file deltas "over the wire" in both directions, from client to server as well as from server to client. In this example, the entire file is only 3,762 bytes, so the savings in network bandwidth isn't all that significant. However, for larger files, the increase in network performance for offsite users can be quite dramatic.
This capability of using binary file deltas between client and server is supported by some other SCM tools as well, including (I believe) Subversion and Perforce.
When the checkin has completed successfully, if I am working in "checkout-edit-checkin" mode, the SCM tool will flip the read-only bit on my working files to prevent me from accidentally making changes without informing the server of my intentions.
Having completed my checkin, the cycle is completed. My working folder is once again worthless, since my changes are a permanent part of the repository. I am ready to start again on my next development task.
Eric Sink is a software developer at SourceGear, which makes source control (aka "version control," "SCM") tools for Windows developers. He founded the AbiWord project and was responsible for much