Using Working Folders in Version Control

Vault client periodically queries the server to ask for the latest version of the repository tree structure. Most of the time, the server will simply respond that "nothing has changed." However, when something has in fact changed, the client receives a list of things which have changed since the last time that client asked for the tree structure.

For example, let's assume Laura retrieves the tree structure and is informed that foo.cpp is at version 7. Later, Wilbur checks in a change to foo.cpp and creates version 8. The next time Laura's Vault client performs a refresh, it will ask the server if there is anything new. The server will send down a list, informing her client that foo.cpp is now at version 8. The actual bits for foo.cpp will not be sent until Laura specifically asks for them. For now, we just want the client to have enough information so that it can inform Laura that her copy of foo.cpp is now "Old."

Operations that Involve a Working Folder

OK, let's go back to speaking a bit more about practical matters. In terms of actually usage, most interaction with your SCM tool happens in and around your working folder. The following operations are the basic things I can do to a working folder:

Make changes

This is the whole point.

Review changes

Show me the changes I have made to my working folder so far.

Undo changes

Some of my changes didn't work out the way I planned. Undo them, restoring my working folder back to the way it was when I started.

Update

The repository has changes which I want to be included in my working folder.

Commit changes

I'm ready to send my changes to the repository and make them permanent.

In the following sections, I will cover each of these operations in a bit more detail.

Make the Changes

The primary thing you do to a working folder is make changes to it. In an idealized world, it would be really nice if the SCM tool didn't have to be involved at all. The developer would simply work, making all kinds of changes to the working folder while the SCM tool eavesdrops, keeping an accurate list of every change that has been made.

Unfortunately, this perfect world isn't quite available. Most operations on a working folder cannot be automatically detected by the SCM client. They must be explicitly indicated by the user. Examples:

It would be unwise for the SCM client to notice that a file is "Missing" and automatically assume it should be deleted from the repository.

Automatically inferring an "Add" operation is similarly unsafe. We don't want our SCM tool automatically adding any file which happens to show up in our working folder.

Rename and move operations also cannot be reliably divined by mere observation of the result. If I rename foo.cpp to bar.cpp, how can my SCM client know what really happened? As far as it can tell, I might have deleted foo.cpp and added bar.cpp as a new file.

All of these so-called "folder-level" operations require the user to explicitly give a command to the SCM tool. The resulting operation is added to the pending change set, which is the list of all changes that are waiting to be committed to the repository.

However, it just so happens that in the most common case, our "eavesdropping" ideal is available. Developers who use the edit-merge-commit model typically do not issue any explicit command telling the SCM tool of their intention to edit a file. The files in their working folder are left in

Pages

About the author

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.