Of these three RA properties, the latter two are truly private to RA,
in that users would never see them, unless someone's debugging the
network layer or something.
But the first (the repository) pokes out into userland. It's
something the user needs to specify on checkout, and something the
user may be interested in inspecting for various reasons. I feel like
it's not part of the network layer's implementation, but rather a
standard, public datum that happens to be used by the network layer.
So my preference would be for #1 to live in the SVN/repository file,
and for #2 and #3 to be properties, as proposed.
Does this seem like good reasoning, or are there strong reasons to
make #1 a property too?
Obviously, libsvn_wc can/will provide an API for reading and writing
the repository information, it's not like ra will ever need to parse
it.
-K
Greg Stein <gstein@lyra.org> writes:
> 1) SVN/repository could be considered an RA property on the directory (not
> sure if we want to use a prop or keep the file, but it is possible)
>
> 2) Each file/directory has a corresponding "version resource" on the server.
> The version resource is specific to the particular file and the revision
> of that file. This URL is analogous to the (file, revision) tuple. RA/DAV
> needs this commit time.
>
> 3) The URL where activities can be created. An activity is needed at commit
> time. It can only be created at a particular URL on the server, and that
> location is discovered via the PROPFIND request method. We use a PROPFIND
> at checkout time, so I get the activity URL at that time (rather than
> doing another round trip at commit time). The URL is then dropped off as
> a property on the directory.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:16 2006