[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 <danielsh_at_elego.de>
Date: Fri, 9 Sep 2011 14:05:45 +0300

Greg Stein wrote on Thu, Sep 08, 2011 at 23:43:04 -0400:
> 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.

Why do you have separate NODES and SHELF_NODES tables then? I'd
intuitively expect the NODES table to be replaced by the SHELF_NODES
table, i.e., every working copy state --- including the one immediately
after 'checkout' --- becomes a shelf. (Though perhaps the first shelf
is 'special' in one or more to-be-determined ways.)

> 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.

Usually want to hack on them concurrently --- i.e., to create a backport
branch and 'make check' it while at the same time adding it to STATUS
and looking at wc-queries.sql on trunk for someone on IRC. Having
multiple shelves within a single working copy isn't good enough for
such use.

Once we have a .svn area shared by multiple working copies, though,
something like that would be useful --- perhaps, 'switch this wc to
the most recent snapshot of branches/fs-progress that you have in .svn'.
('svn switch ^/subversion/branches/fs-progress_at_WCDB', or perhaps give it
a symbolic name (and make 'update' change what the symbolic name points
Received on 2011-09-09 13:06:48 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.