Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> I see. I think I see. I sort of assumed we're using the same sort of
> revision numbering as RCS/CVS, which encode the branch structure in the
> revision numbers.
>
> How are we going to encode the branch structure, then? I can imagine
> properties on the root dir linking the nodes into a tree, but that won't
> work deeper down in in the tree. This would make "svn log" very
> inefficient, wouldn't it?
I don't think so. Each node revision should have a pointer back to
the filesystem revision in which it was created. (This isn't
described in `structure' at the moment.) To construct the log of a
file or directory, you start with its current revision and walk
backwards, producing the message of each filesystem revision in which
a new revision of the file or directory was created.
You'll need to explain in more detail what you think will be
inefficient.
> I'm trying to wrap my head around this idea, see what we gain ... O.K.,
> copies will be a bit faster, although not much (in fact, we don't gain
> for file copies). But it occurs to me that we'll be throwing away
> information that would be useful for things like "svn log", tools like
> the revision tree browser, etc.
What we gain, I think, is a simpler repository structure, and thus a
more reliable repository. Since we have a single mechanism that we
put to use in several ways, we just need to get that right, and
everything else will work.
This is why there are property lists everywhere you look. They are
supposed to be the hooks you use to implement higher-level structures,
like the more detailed ancestry information a revision tree browser
would need. Assuming the hooks are adequate, we can experiment with
different designs for this ancestry info without rewriting the
filesystem, and without even losing whatever history we've already
committed. (Granted, new structures don't magically retroactively
appear on older revisions, but I think one can deal with that, and at
the least, it's no worse than changing the filesystem structure.)
It may be that property lists are not sufficient, don't do the right
thing, etc. So we'll need to change things as we learn. But I think
the basic idea --- that the filesystem structure should be really
simple, and you build complicated semantics on top of that, rather
than building them into the fundamental structure and weakening the
whole system --- is the way to go.
> On the other hand, it occurs to me that we could have used a simpler
> revision numbering scheme if we only use ti to encode successor/ancestor
> relationships. In the current scheme, the node and revision numbers can
> become really long, and in practice they probably will, too. (Unlike the
> branch structure in the configuration management sense, which has to be
> simple enough for users to understand, creating a successor node won't
> have a visible impact on the complexity of the repository. But it will
> keep on adding pairs of numbers to our node IDs.)
Yeah, the always-growing revision numbers bother me, too. I thought
about doing something similar to your suggestion (although your
proposal is more graceful than what I had in mind). However, the
advantage that the RCS-style numbers have is that, given two revision
numbers, you can determine their relationship (if any) simply by
inspecting the numbers --- no I/O is necessary. In your system, you
might need to walk the node's entire history in the database before
you could be sure they weren't related. This ability to quickly
recognize related nodes was useful in computing deltas.
It's not like this is a killer advantage. The delta algorithm has
other limitations; perhaps removing them would make this advantage
useless. But that's the rationale, anyway.
It's worth noting that you only get branchy revision numbers when
there's actual contention on a file. In the common case, you'll just
get ordinary revision increments. However, once you do get a branchy
revision number, you're stuck with it forever.
Received on Sat Oct 21 14:36:21 2006