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

On Thu, Feb 15, 2001 at 11:24:23AM -0500, Jim Blandy wrote:
> Greg Stein <gstein@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/