Hi Jeffrey, Thanks for writing. Stefan answers most of the high points, and I'll describe my own thoughts in-line below. Myself, or anyone that beats me to it, should probably start a notes/shelving document.
Below: On Wed, Sep 7, 2011 at 03:51, Stefan Sperling <s...@elego.de> wrote: > 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? >... > 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. Right. > 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. This was my thought. To be more concrete: Create a new SHELVED_NODES table, modeled almost exactly like NODES. One more column would be added to primary key, 'shelf_id'. When changes are shelved, we create an ID for that shelving, and then move all nodes with op_depth > 0 into SHELVED. Second, we have a SHELVED_ACTUAL table, modeled after ACTUAL_NODE with two more columns: 'shelf_id', 'actual_checksum'. The ACTUAL_NODE contents would be moved into this table, with the ID from above. The contents of the file would be moved into the pristine system, and the checksum stored into 'actual_checksum'. We also need some details from op_depth==0. For example, what revision are the text/prop changes against? Tree changes such as add/copy don't need data from BASE (I think), but move/delete is removing a specific revision. When the shelf is restored, we need to deal with conflicts around those moves/deletions. Hmm. We may need more info from BASE for adds. For example, before shelving, it may be just an add (no BASE). But when unshelving, a node exists, which means an add/add conflict. ... anyway. That is the basic approach that I was considering for the feature. We can capture the entire state with these extra couple tables. >... > 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). I think unshelving can create a full set of conflicts. As above, even a simple add/add conflict. If local mods exist, then we can simple disallow the unshelving. For now. With some additional work on conflict handling, we could do a full merge of the local mods and the shelved mods. >... Cheers, -g
