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.
