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@WCDB', or perhaps give it
a symbolic name (and make 'update' change what the symbolic name points
to).
