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