Re: identifying FS nodes

> The point is simply: an svn_fs_id_t does not properly/completely identify a
> resource in the repository. The path is also required.

Yep, that one's a kicker. I have to repeat to myself ten times every
day:

    Node revision ID's are not inode numbers.

It would be possible to make node revision ID's act like inode
numbers. Copying a file would create a new NRID; renaming it
wouldn't; copying a tree would creating new NRID's for all the nodes
in the tree. It's even possible, I think, to do that lazily, and keep
most of the performance wins we get from the current structure.
The work is equivalent to that required to support hard links.

But the scheme I came up with has some disadvantages: the length of an
NRID would depend on how many times it had been copied, even if no
change had been made to its contents. After all, it's a distinct
thing; it needs a distinct name. After a while, you're talking about
some pretty long NRID's. The current structure only makes longer
NRID's when you have two modified NR's based on the same original.

> It would seem that I'll need to alter the strategy to create URLs of the
> form: http://www.lyra.org/repos/$svn/ver/672/foo/bar.c (where 672 is the
> revision number).
>
> Does this seem like the right approach?

It depends. Suppose revision 673 doesn't touch anything in /foo.
Then 672/foo/bar.c and 673/foo/bar.c are two different names for the
same "resource", right? Is that acceptable?
Received on Sat Oct 21 14:36:17 2006