On Thu, Sep 8, 2011 at 19:33, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Stefan Sperling wrote on Thu, Sep 08, 2011 at 00:36:05 +0200:
>...
>> Sure. But in the initial implementation we could just restore the former
>> working copy state, including mixed-revisioness etc. Just rewind everything
>> back to where it was and let a subsequent update sort out the conflicts.
>> That would already be a big improvement over the diff/patch approach.
To do this, we'd also want to move op_depth==0 over to the
SHELF_NODES. Probably a good idea to just copy all of it, rather than
piecemeal like I suggested, as I suspect that we'd eventually find a
reason to have BASE present.
> If we do this, it would be nice if 'restore the former state' could be
> done offline --- e.g., by retaining the relevant pristines as long as
> the shelf exists.
Absolutely. There shouldn't be *any* reason to contact the server. All
the pristines would be held via SHELF_NODES and SHELF_ACTUAL.
> (Now, if the working copy is at state S and someone asks to return to
> a previously-shelved state, what do we do with S? Do we discard it, or
> do we first save it somewhere? And if we save it... do we save it as
> a new shelf?)
I *do* envision multiple shelves, and that makes it (imo) even more
important to look at "unshelve" as merging changes onto the current
state.
Regarding current state S... I think "unshelve" should NOT be allowed
if local mods exist. Thus, we never need to worry about S. The user
can always explicitly shelve that, return to a no-mods state, and then
unshelve state-R.
And yes, we can have an --ignore-local-mods switch to unshelve even
when local mods exist.
Also consider: the shelves can then act as multiplexors for the
working copy. You could have one shelf for trunk, one for
branches/1.7.x, one for 1.6.x, one for branches/fs-successor-ids, and
for some trunk changes that you set aside.
I've had to use git lately, and our shelves could almost look like
git's branches. Swap around among them based on what you're doing at
the time.
Cheers,
-g
Received on 2011-09-09 05:43:51 CEST