Greg Stein wrote on Thu, Sep 08, 2011 at 23:43:04 -0400: > On Thu, Sep 8, 2011 at 19:33, Daniel Shahaf <d...@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
