Using Working Folders in Version Control

Source Control HOWTO - Chapter 5

I just changed my mind.  In any case, a very nice feature of a working folder is the ability to undo.

In the case of a folder-level operation, perhaps the Undo command should actually be called "Nevermind."  After all, the operation is pending.  It hasn't happened yet.  I'm not really saying that I want to Undo something which has already happened.  Rather, I am just saying that I no longer want to do something that I previously said I did.

For example, if I tell the Vault client to delete a file, the file isn't really deleted until a commit that change to the repository.  In the meantime, it is merely waiting around in my pending change set.  If I then tell the Vault client to Undo this operation, the only thing that actually has to happen is to remove it from my pending change set.

Best Practice: Be Careful with Undo

When you tell your SCM client to undo the changes you have made to a file, those changes will be lost. If your working folder has become valuable, be careful with it.

In the case of a modified file, the Undo command simply overwrites the working file with the "baseline" version, the one that I last retrieved.  Since Vault has been keeping a copy of this baseline version, it merely needs to copy this baseline file from its place in the hidden state information over the working file.

For users who use the checkout-edit-checkin style of development, closely related here is the need to undo a checkout.  This is essentially similar to undoing the changes in a file, but involves the extra step of informing the server that I no longer want the file to be checked out.

Digression: Your Skillet is not a Working Folder

Source control tools have been a daily part of my life for well over a decade.  I can't imagine doing software development without them.  In fact, I have developed habits that occasionally threaten my mental health.  Things would be so much easier if the concept of a working folder were available in other areas of life:

  • "Hmmm.  I can't remember which of these pool chemicals I have already done.  Luckily, I can just diff against the version of the pool water from an hour ago and see exactly what changes I have made."
  • "Boy am I glad I remembered to set the read-only bit on my front lawn to remind me that I'm not supposed to cut the grass until a week after the fertilizer was applied."
  • "No worries -- if I accidentally put too much pepper on this chicken, I can just revert to the latest version in the repository."

Unfortunately, SCM tools are unique.  When I make a mistake in my woodshop, I can't undo it.  Only in software development do I have the luxury of a working folder.  It's a place where I can work without constantly worrying about making a mistake.  It's a place where I can work without having to be too careful.  It's a place where I can experiment with ideas that may not work out.  I wish I had working folders everywhere.

Update the Working Folder

Ten milliseconds after I retrieve a fresh working folder, it might be out of date.  An SCM repository is a busy hub of activity.  New stuff arrives regularly as team members finish tasks and checkin their work.

I don't like to let my working folder get too far behind the current state of the repository.  SCM tools typically allow the user to invoke a diff tool to compare

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.