FS API requests

[Greg Stein <gs...@lyra.org>]

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() ]

*) 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?

*) still need the "latest revision" API that I can pass to svn_fs_open_root


That's it for now :-) ... more if/when I find them.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: FS API requests

[Greg Stein <gs...@lyra.org>]

On Sun, Nov 26, 2000 at 05:06:26PM -0500, Jim Blandy wrote:
> Greg Stein <gs...@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)
>...
> ... no, that won't work because ...

Ah. Gotcha... that makes a lot of sense. Never mind, then :-)

[ good thing they're requests rather than demands :-) ]

>...
> > *) 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.

Okay. I'll drop in some pseudo-code to fill out these things, then we can
plug in the "real thing" later.

Note that the above properties are "read only", so they are *quite* like
other properties.

> > *) still need the "latest revision" API that I can pass to svn_fs_open_root
> 
> Sorry.  Will provide soon.

No time pressure, just a friendly reminder that I'll need it at some point.

> > That's it for now :-) ... more if/when I find them.
> 
> Keep 'em coming!

:-)

There will probably be quite a few when I get to the "reporting" part. That
is where I need to query stuff like "is there any difference between <this>
revision and <that> revision?" Or "is <this> revision of file <xyz> up to
date?"

Not sure what the specific demands are yet. I also need to review/revise the
webdav-usage document for some recent changes in DeltaV. I doubt that I'll
have a firm grasp until I dig in and write code, though. Too many variables
at unknowns right now.

Thanks!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: FS API requests

[Jim Blandy <ji...@zwingli.cygnus.com>]

Greg Stein <gs...@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!