Jim Blandy <jimb@zwingli.cygnus.com> writes:
> 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.
+1.
Of course we can't guarantee in advance that this will be everything
we ever need. But it sure looks like it will, and I would be very
surprised if a major revamp is necessary at any point.
> 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.
I could be wrong about this, but I think the branchy revision numbers
are an inescapable result of needing to support a potentially infinite
amount of contention within a discrete system. Like the Dewey Decimal
System (or whatever your favorite cataloger is), we have to support
the insertion of new entities between any two existing entities, and
additionally it's desirable that ancestry relationships be apparent by
inspection.
With requirements like that, we almost can't avoid uneven number
growth. The length of a number no longer has much to do with its
"importance"... However, conceptually, this should be pretty easy for
us to get used to. I mean, no one thinks differently about a book
just because it has a long and undistinguished Dewey Decimal number.
-K
Received on Sat Oct 21 14:36:21 2006