[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Thoughts about issue #3625 (shelving)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 9 Sep 2011 02:33:30 +0300

Stefan Sperling wrote on Thu, Sep 08, 2011 at 00:36:05 +0200:
> On Wed, Sep 07, 2011 at 05:48:47PM -0400, Greg Stein wrote:
> > On Wed, Sep 7, 2011 at 03:51, Stefan Sperling <stsp_at_elego.de> wrote:
> > > 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.
> 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.

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.

(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?)
Received on 2011-09-09 01:34:11 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.