On Fri, Sep 9, 2011 at 07:05, Daniel Shahaf <danielsh_at_elego.de> wrote:
> 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.)
True! Could certainly do that. A little trickier to upgrade, and lots
queries would need to be altered... but sure. We'd only have to take
that hit once, and add a 'shelf_id' to the NODES table.
>> 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.
Yup. Just saying.
Greg Hudson said this is more akin to git stash than branches. I
haven't used git's stashes to see how it actually differs from
branches. I guess it is simply that changing branches leaves local
mods, rather than stashing pseudo-reverts the local mods.
> 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
I've found that git has symbolic names for repositories. Kinda handy
to refer to "myrepos" vs "upstream", rather than remembering the URLs.
Received on 2011-09-09 14:17:11 CEST