> 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
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