open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

On Wed, Feb 14, 2001 at 09:24:07AM -0500, Jim Blandy wrote:
> Karl Fogel <kf...@galois.ch.collab.net> writes:
>...
> > A dag_node_t is currently something we can retrieve by key (see
> > svn_fs_id_t).  The value associated with that key knows nothing about
> > parent information.  So if dag_node_t had a parent fields, then when
> > we retrieve a dag_node_t it would have to be incomplete.
> 
> For what it's worth, that interface (creating a dag_node_t given a
> node ID) was only needed by the clone tracking stuff.  So that
> function could go away.

Um... a while back, I requested a way to get at a node, given an ID. The
only thing that I need is read-access to the file contents and its
properties. No changes, no parent info, nada.

Cheers,
-g

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

Re: open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

On Mon, Feb 19, 2001 at 04:01:19PM -0500, Jim Blandy wrote:
> 
> Greg Stein <gs...@lyra.org> writes:
> > That would be fine, as long as the ID remains the same for an file that
> > wasn't changed from R1 to R2.
> 
> So the ID would be the basis for caching?

Yup.

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

Re: open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

Greg Stein <gs...@lyra.org> writes:
> That would be fine, as long as the ID remains the same for an file that
> wasn't changed from R1 to R2.

So the ID would be the basis for caching?

Re: open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

On Fri, Feb 16, 2001 at 11:07:59AM -0500, Jim Blandy wrote:
> Greg Stein <gs...@lyra.org> writes:
> > > What's the larger picture?  Do you need this for nodes in a
> > > transaction, committed nodes, or both?
> > 
> > Committed nodes only. This is for "svn checkout" or "svn update" -- fetching
> > the file contents and properties. The node ID is the most stable form
> > (perfectly stable, in fact) for referring to a node (imagine that).
> 
> How about I generate ID's for you?  They'd be opaque byte strings.

That would be fine, as long as the ID remains the same for an file that
wasn't changed from R1 to R2.

I'm using "ID/PATH" as the unique value.

Cheers,
-g

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

Re: open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

Greg Stein <gs...@lyra.org> writes:
> > What's the larger picture?  Do you need this for nodes in a
> > transaction, committed nodes, or both?
> 
> Committed nodes only. This is for "svn checkout" or "svn update" -- fetching
> the file contents and properties. The node ID is the most stable form
> (perfectly stable, in fact) for referring to a node (imagine that).

How about I generate ID's for you?  They'd be opaque byte strings.
[looks innocent]

Re: open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

On Thu, Feb 15, 2001 at 11:24:23AM -0500, Jim Blandy wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > Um... a while back, I requested a way to get at a node, given an ID. The
> > only thing that I need is read-access to the file contents and its
> > properties. No changes, no parent info, nada.
> 
> Sorry --- I'd forgotten about that.
> 
> This is going to be problematic.  For example, you can't tell whether
> you're authorized to access the file without knowing whether you're
> authorized to access its parent directories.

Hrm. You're right. I *do* have the path, tho!

However, I can't tell you the root (revision) that the path is relative to.
It can be inferred from "use largest value R such that path P refers to node
id N." I'll give you P and N.

It would be an error to have P that doesn't refer to N in any revision.
(this bad query form could happen due to a bad client or a user typing in a
bad URL)

[ note: from an ACL standpoint, I'd think the ACL applies mostly to the node
  itself so that a copy/move doesn't accidentally expose something on
  another path; but I know that's a big debate and I don't think it is
  actually relevant to the above ]

[ I will also posit that the ACL would be the same across all revisions
  where P refers to N, so it shouldn't matter which one you select; if we
  say that it *does* matter, then using the latest should be fine; I would
  hope that somebody can't access rev 6 to skip the ACL that was emplaced in
  rev 7. ]

> What's the larger picture?  Do you need this for nodes in a
> transaction, committed nodes, or both?

Committed nodes only. This is for "svn checkout" or "svn update" -- fetching
the file contents and properties. The node ID is the most stable form
(perfectly stable, in fact) for referring to a node (imagine that).

Transaction nodes appear in a different URL space; I'll always have the
transaction ID and and path.

Cheers,
-g

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

Re: open by ID (was: Re: New FS API, open_path, cloning and dag_node_t)

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

Greg Stein <gs...@lyra.org> writes:
> On Wed, Feb 14, 2001 at 09:24:07AM -0500, Jim Blandy wrote:
> > Karl Fogel <kf...@galois.ch.collab.net> writes:
> >...
> > > A dag_node_t is currently something we can retrieve by key (see
> > > svn_fs_id_t).  The value associated with that key knows nothing about
> > > parent information.  So if dag_node_t had a parent fields, then when
> > > we retrieve a dag_node_t it would have to be incomplete.
> > 
> > For what it's worth, that interface (creating a dag_node_t given a
> > node ID) was only needed by the clone tracking stuff.  So that
> > function could go away.
> 
> Um... a while back, I requested a way to get at a node, given an ID. The
> only thing that I need is read-access to the file contents and its
> properties. No changes, no parent info, nada.

Sorry --- I'd forgotten about that.

This is going to be problematic.  For example, you can't tell whether
you're authorized to access the file without knowing whether you're
authorized to access its parent directories.

What's the larger picture?  Do you need this for nodes in a
transaction, committed nodes, or both?