Wednesday, May 19, 2010

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.

4 comments:

Andreas Krey said...

It took me a while to find out what is wrong here. In git, the stash was very simple to implement because it is stored simply as two commits (for current working directory and current index) in the regular repository, making it accessible to repository browsers and generally the whole tool chain.

git stash looks like a natural extension of git's concept of handling change sets. svn stash looks more look like a 'me too' bolt-on to me.

Karl Fogel said...

I think Greg's parenthetical mention of "git stash" and "hg stash" might have distracted from where the motivation for this feature comes from:

People have wanted this in Subversion for a long time, since the beginning of the project. It didn't happen until now partly because there were other higher priorities, and partly because the architecture of Subversion's working copy made it somewhat difficult. Now the feature's time has come, with WC-NG.

So it's not a "me too" in the sense of being a reaction to the DVCS systems, although it's true (as you point out) that it was very easy for those systems to implement from the start, which is why they had it earlier.

Karl Fogel said...

And let me add: I'm one of the people who wants it, a lot :-). So three cheers!

kAlvaro said...

I'm really excited about wc-ng. From what I've read and understood, it appears that centralized storage will finally make working copies usable in network drives. Oh my, I will probably be able to re-enable status icons in TortoiseSVN!

I'd like to ask a few assorted questions:

1. Will third-party tools require many changes to operate on wc-ng?

2. Are true renames in your planning? Would that dismiss tree conflicts when merging?

3. Full rewrite of working-copy format only bumps version number to 1.7... What are you planning for Subversion 2? :)

Keep on the good work.