Wednesday, December 19, 2007

Using patch as a subversion stash

Being a consultant, I'm generally at the mercy of whatever source control system my current client is using. Luckily, Subversion has been the version control choice for every client I've worked for in the past 3 years.

A friend of mine, Kurt Schrader, recently posted The Power of Git: git-stash. I haven't gotten a chance to use git, but I am planning to give it a shot in the near future. However, I don't expect to being using git for daily development any time soon.

I've definitely needed a git-stash in the past. It's helpful for fixing a bug without committing your current changes, but it's also helpful if I ever get to work and I end up on a pairing station that has someone else's uncommitted changes.

In those cases I create a patch, revert the changes and move on.

In case you're unfamiliar with this type of thing, here's all you'll need to do (assuming you have patch available).

Creating the patch: svn diff > patch_name.patch

note: You'll want to add any new files before creating the patch, if you want them included in the patch.

Once you've created the patch you can revert everything and start fresh (svn revert -R . will recursively revert). You may also need to delete any new files that were created as part of the uncommitted changes (Paul Gross has a one liner for removing uncommitted files).

When you are ready to get your changes back you'll need to apply the patch that was previously created.

Applying a patch: patch -p0 < patch_name.patch

That's basically it for decent stash capabilities with Subversion, but there is one gotcha: patch will not capture Subversion metadata changes. Usually this isn't a problem, but it's always a good idea to look out for this situation when you create a patch.

7 comments:

  1. Jay, if you're interested in learning git but are stuck with using Subversion, take a look at git-svn if you haven't already. My workplace has already migrated to git save for one project, which has to remain as Subversion due to an external developer. In-house though, we use git-svn to work with the codebase, and haven't encountered any problems so far.

    ReplyDelete
  2. Anonymous12:33 PM

    I've found myself doing this, more or less, for some time.

    The only thing I haven't figured out is a good place to store them.

    I don't like to leave them in the checkout, because they'll appear in 'svn st'. I don't really want to put them anywhere else though, because I'd likely forget about the patch.

    ReplyDelete
  3. @technicalpickles - perhaps create a patches folder, and set svn to ignore it.

    ReplyDelete
  4. Anonymous7:46 PM

    Jay: svk, if you are stuck on svn at work and not looking to deal with git-svn? The you can quick branch locally, which is sorta what git-stash is doing.

    @technicalpickles - add *.patch to your global/user svn ignore (~/.subversion/config)

    ReplyDelete
  5. Even easier, and it does preserve metadata changes:

    > cd ..
    > cp -R myproj myproj2
    > cd myproj2
    > svn revert -R .
    make make changes and commit

    ReplyDelete
  6. Anonymous8:02 PM

    Suppose your changes will conflict with your previously created patch.
    What do you do in this case?

    ReplyDelete
  7. I wrote some simple shell scripts to automate this for me, since I find myself doing it often (and thought git stash was useful).

    http://www.blisted.org/blog/bin/svn/stash

    It behaves similarly to git stash, and creates stashes by creating patches and disintegrating/reintegrating them into the working copy.

    ReplyDelete

Note: Only a member of this blog may post a comment.