svn stash

This is the third of (at least four) posts in my miniseries about Subversion's next-generation working copy library. See the introduction and what we're doing to fix things.

Once we have this fancy new code, it will provide a stable and robust base for building new features. The DVCS systems have done a great job exploring new areas and needs of version control users. One feature in particular is called stashing or shelving (see "git stash" and "hg shelve").

For those not familiar with the stash concept: consider the scenario where you've been doing some work, and a high-priority bug arrives, needing to be fixed right away. Classically, a Subversion user would check out a fresh working copy, fix the bug, perform the commit, and go back to their work in the original working copy. Instead, when using stash, it takes all of your current work and sets it aside, leaving you with an unchanged working copy, ready for your bug-fix work. After your commit, you retrieve the changes that were stashed. The presumption here, of course, is that stashing is a much faster and simpler operation than setting up a new working copy.

We'll be able implement this feature quite easily using the WC-NG datastore. It will take just a few operations:

1. preserve all metadata about local changes
2. place a copy of each locally-modified into pristine storage, recording their SHA-1 key with the stashed metadata
3. revert all local changes

Since the metadata is recorded in a single SQLite database, step 1 is "simply" some copying of those changes off to a separate set of tables. The pristine storage is a generalized mapping of SHA-1 keys to file contents that we'll be using for storing more things (such as merge sources, pending conflict resolution), so it can easily hold stashed items. And step 3 has been in Subversion for a long time :-)

Recovering the changes from the stash is effectively running a big "svn merge" operation. The merge is required because you may have made other changes to the working copy (your bug-fix) and/or updated to the latest revision.

Other features, such as multiple stashes, management of those changes, applying subsets, and whatnot would be added, too. The feature set has not (yet) been designed, so I have no idea what is required or how we would present this to our users. We'll definitely be looking at git and hg as we explore the needs around stashing/shelving.

"When?" is your next question, I'm sure :-) ... Well, we're releasing WC-NG in Subversion 1.7. That will probably happen this fall. We want to get those changes out the door since that will mark 18 months of development time. WC-NG is a feature in itself, and we want to get it into people's hands without further delays [waiting for additional features]. After that, I'm interested in adding stash support (and a "checkpoint" feature (described in my next post)). So let's say stashing will appear in 1.8 which should be released around this time next year.

Heading to Berlin!

In June, in Berlin, elego is hosting a "Subversion Day", along with workshops and a hackathon/sprint. And with great thanks to elego, I will be able to attend and contribute to the event. I'll be in Berlin from June 9th through the 14th.

As always, I'm looking forward to meeting up with my fellow Subversion developers, but there are quite a few others in Berlin that I want to spend time with. Torsten, Valerie, Erik -- I'm looking at you! Julian: road trip from Münster? Who else am I missing? Torsten says that he'll arrange for one of the regular Apache-people dinners. Want to join?