[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Thoughts about issue #3625 (shelving)

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 7 Sep 2011 09:51:06 +0200

On Wed, Sep 07, 2011 at 12:53:38AM -0400, Jeffrey Pierson wrote:
> With the new patch features from 1.7 would it make sense to implement this
> feature internally as a stored patch with some extra changes to the client
> to allow exporting the shelved changes as a patch and more obviously shelve
> and unshelve?

What extra changes do you have in mind?

It is possible to shelve a set of changes like this:

  svn diff > mypatch
  svn revert -R .

and unshelve them later:

  svn revert -R .
  svn patch mypatch

There are caveats with using patches for shelving (with or without
an internal mechanism to handle the shelved patch):

 1) svn patch does not support all kinds of tree changes. For instance,
   If your saved changes included copy operations they will appear as
   additions after applying the patch. If your saved changes included
   replaced directory trees, with some of the children of the replacing
   tree having been deleted or also replaced, a patch cannot represent that.

A first-class 'shelving' feature would save the entire state of the
working copy database. It could represent the shelved state with much
more accuracy than is possible with a patch file -- it could preserve
all types of tree changes, conflict markers, etc.

 2) svn patch cannot do a 3-way merge. If the working copy state has
   changed in an incompatible way you'll get rejects instead of conflicts.
   To mitigate this problem you can update back in time to the revision
   the patch was made against before applying the patch.
   But this can get tedious if the diff was made from a mixed-revision
   working copy. Every path affected by the patch might have to be
   updated to some other revision. Of course, a Subversion client could
   automate this as part of a 'shelving' implementation based on 'svn diff'
   and 'svn patch'.

A first-class 'shelving' feature wouldn't have to worry about conflicts.
It would simply restore the working copy to the shelved state (either
destroying unrelated local modifications, or raising an error in case
of their presence).

> As a TortoiseSVN user I'm thinking such feature could be added to an
> individual client as a internally managed patch without any changes to the
> core SVN API. This being said, client side API changes would make it more
> widely adoptable and consistent. My guess is that with or without this
> feature, clients will like grow this feature post 1.7 because of the patch
> enhancements.

I don't think there is a huge problem with clients building shelving
support on top of svn diff and svn patch. As soon as Subversion supports
shelving as a first class feature these clients can replace their custom
implementation with API calls into the Subversion libraries.

Note that the very same thing happened with 'svn patch' and TortoiseSVN.
TortoiseSVN has had a 'patch' feature even before Subversion 1.7 existed.
TortoiseSVN's own patch implementation was basic. I don't think it supported
changes to properties, or even patching lines that had moved elsewhere in
the patch target. TortoiseSVN versions based on Subversion 1.7 replaced the
custom 'patch' implementation with a call into Subversion's libraries.
TortoiseSVN gained new functionality for its existing 'patch' feature.
Received on 2011-09-07 09:51:56 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.