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 <stsp_at_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
Received on 2011-09-07 23:49:17 CEST