Re: Filesystem structure question

Alon Ziv wrote:

> Just to add another data point, we should also consider what happens when
> (post-1.0) Subversion supports cross-repository links. This means we may have
> two seemingly independent nodes, where just the ancestry reveals they
> originated from the same node in another repo...

Do we want to store different revisions of the same node in different
repositories?

It's doable, and existing CM systems have that capability (e.g.,
ClearCase); but in practice it's a maintenance nightmare. I'd definitely
steer away from that, especially if we want to our promise that commits
are atomic; otherwise, we'd have to support distributed transactions.
That's hairy.

(It's a relatively clean way for creating real distributed repositories,
though, with each site having its own branch of the same tree.)

> IMO, the best approach would be to just use plain nodes + version# (w/o branch
> marks in the versions) and to use e.g. topological sort on the ancestry set to
> detect 'related' nodes.

That's a fine idea, but it has a rather large caveat: if the sort can't
be implemented using the database's btree indices, you need to do an
index lookup for every node revision when you walk the revision DAG.
This can become expensive, e.g., when looking for the closest common
ancestor during a three-way merge between branches.

Not trying to slap you down, just pointing out problems I've seen in
similar setups. :-)

-- 
Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/