Greg Stein <gstein@lyra.org> writes:
>
> Some random requests for the FS API:
>
> *) svn_fs_dirent_t returns an svn_fs_id_t for a node. It would be nice to be
> able to use that for opening the child node (rather than path
> construction, and making the FS do the path->node mapping)
> [ basically: I think this means expose svn_fs__open_node_by_id()
> ]
Hmm. Suppose you have two processes working on the same transaction.
- Process A calls svn_fs_dir_entries on a directory D, which is so far
unmodified.
- Process B modifies the file D/F. This clones that file node, so now
D/F refers to a different node ID than appears in A's list.
- Process A now decides to open D/F using the optimization you suggest,
and gets the pre-cloned file, not the clone as it should.
Since A can always simply call svn_fs_open_node and supply D as the
parent directory, which is only a single directory search, I don't
think exposing open_node_by_id is worth the trouble.
The filesystem interface is going to handle clone tracking
transparently, so the fact that D gets cloned (and thus gets a new ID)
while A has it open isn't a problem. See my recent commits to
libsvn_fs/structure for the details.
> *) there are two properties that DAV needs:
>
> - creation date (when was the resource created)
> - last modified date (for this revision)
>
> Will the FS track either/both of these (and provide an API), or should I
> (manually) keep these in a property?
If the FS does provide an API, it'll just be a layer on top of the
properties. So it doesn't make much difference either way.
> *) still need the "latest revision" API that I can pass to svn_fs_open_root
Sorry. Will provide soon.
> That's it for now :-) ... more if/when I find them.
Keep 'em coming!
Received on Sat Oct 21 14:36:15 2006