Greg Stein wrote on Thu, Sep 08, 2011 at 23:43:04 -0400:
> 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.
>
Forward-porting of patches? i.e., locally maintaining a patch on top of
upstream source? And then when you port the patch it might be nice to
do a 3-way merge (old BASE, new BASE, (old BASE)+patch -> (new BASE)+patch).
> > 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.
>
Thought so, just calling out the functional aspect (offline unshelving)
as opposed to the implementation one (this and that tables).
> > (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.
>
No one said that there are local mods in S; it might be a state with
various mixed-revisions and switched trees, but no local mods. The
problems that these two introduce might be similar to the problem that
'plain' local mods (text/prop edits) introduce, though?
> 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 13:14:20 CEST