Temporarily put away uncommited changes in Subversion (a la "git-stash")

Question

While programming software stored in a Subversion repo, I often modify some files, then notice that I'd like to do some preparatory change for my main work. E.g. while implementing new functionality, I notice some refactoring which might help me.

In order not to mix two unrelated changes, in these cases I'd like to "stow away" my changes, i.e. revert to the repository version, do some other changes, commit these, then "fetch back" my changes.

git-stash allows to do just that. Is there some way to do this with Subversion, either directly or with some plugin or script. Eclipse plugins would also be fine.

Answer 1

I have also wanted this feature. I currently use TortoiseSVN.

I have not found a hardfast solution except to export the tree, revert back to repository make my changes and commit, then compare the changes from the exported tree back into my source controlled directory using a tool like Beyond Compare.

Or, another solution might be to branch from the HEAD to another directory, make your changes and the commit. Once you're ready to merge those back to your other working copy, do an update and merge your changes.

Answer 2

Obvious way would be using multiple working copies, involving an additional checkout which is a bit expensive.

Alternatively, since Subversion can do branching faster than a physical copy operation, you can "checkin" your current changes to a temporary branch and switch back and forth.

If your changes do not overlap, you can put them in separate changelists to manage multiple checkins.

Answer 3

The easiest way would be to use a temporary branch, like this:

$ svn copy ^/trunk ^/branches/tempbranch
$ svn switch ^/branches/tempbranch
$ svn commit -m "Stashed"
$ svn switch ^/trunk
$ ... hack away in trunk ...
$ svn commit -m "..."
$ svn merge ^/branches/tempbranch .
$ svn rm ^/branches/tempbranch
$ ... continue hacking

This could (and probably should) be put in a script if done on a more regular basis.

Answer 4

when I've got uncommitted changes from one task in my working copy and I need to switch to another task, I do one of two things:

Check out a new working copy for the second task.

or

Start a branch:

workingcopy$ svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
workingcopy$ svn switch SOME_BRANCH
workingcopy$ svn commit -m "work in progress"
workingcoyp$ svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE

I have some scripts that help to automate this.

Answer 5

you can store your current changes with svn diff into a patch file, then revert your working copy:

svn diff > stash.patch
svn revert -r .

after you’ve implemented your preparatory feature, you can then apply your patch with the patch utility:

patch < stash.patch

as others have noted this will not work with svn:properties and tree operations (add, remove, rename files and directories).

binary files could also give problems, i don’t know how patch (or tortoisesvn in this case handles them)

Answer 6

another option is to copy your current checkout to a new directory and revert all your changes. this way you’ll save the hassle of creating a temporary branch on your server—after all stashing is a local operation, which not everybody should see and can be done quite often.

after committing your hotfix you can update your main working copy and delete your “stashing area”

Answer 7

I don't know of an easy way to do that with just svn. Honestly, I'd advise using git-svn to make a git repo that acts as an svn working copy, and just using git stash with that. Just replace git pull with git svn rebase and git push with git svn dcommit and you can actually keep 90% of your git workflow and still be talking to an svn server.

Answer 8

This blog post advises using diff and patch.

• git stash approximately becomes svn diff > patch_name.patch; svn revert -R .
• git stash apply becomes patch -p0 < patch_name.patch

Note that this doesn't stash metadata changes or (I think) directory creates/deletes. (Yes, svn tracks those separately from directory contents, unlike git.)