Greg Hudson wrote:
> I read the libsvn_fs structure document yesterday (which I believe Ben
> has been updating, so I think it's reasonably current), and am unclear
> about the motivation behind hierarchical node-revision IDs.
>
> What would fail if we threw out the concept of "nodes" and dealt only
> in terms of node-revisions? (Perhaps they'd get a simpler name, but
> I'll continue to use the term "node-revision" for consistency.) A
> node-revision would have a simple numeric ID.
>
> I'm guessing that I'm missing something having to do with the storage
> of node-revision contents as deltas. But I'm not sure why we can't
> just allow the contents of a node-revision to be ("delta" RELATIVE-TO
> DELTA CHECKSUM) where RELATIVE-TO is another node-revision-id, instead
> of having a "younger" which is implicitly relative to the next-younger
> revision.
>
> Thanks for indulging me.
Jim is the final authority here, but I'll try:
With the current scheme, the version tree of a node is indexed. You can
find whole branches, tips, branchpoints, etc. with a single query into
the "nodes" table. With your scheme, all that information would have to
be storead explicitly in the tables with pointers between nodes. We'd
have to maintain the version tree by hand, opening a door for
consistency problems. It would also slow down certain kinds of
operations, like branching.
--
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/
Received on Sat Oct 21 14:36:16 2006