"Morten Ludvigsen" <morten@2ps.dk> writes:
> > In our particular implementation, we just *happened* to decide that
> > the public URI space would represent the HEAD revision.... we're free
> > to choose what we want public resources to represent. We didn't have
> > to do that; we could have decided to have no public URIs at all. We
> > could have decided that to get any file from *any* revision, you'd have
> > to make a specific set of DeltaV queries... but we didn't. It seemed
> > friendlier to make a public URI mean "the resource from the latest
> > revision."
> >
>
> Yes - it is friendly. That is one of the (many) reasons why I have chosen
> Subversion :-) Can I rely on this "friendliness" to stay the same?
I think so, yes. :-)
> Maybe in the future - but right now I am writing middleware that will
> use Subversion as a read-only "database". All I need is to be able to
> fetch a version (as in "tag" not "revision" :-) of a file using HTTP
> and know that that version will never change.
In Subversion, a specific incarnation of a file is uniquely defined
by an pair of coordinates: (revision, path).
To retrieve an opaque URL that represents these coordinates, you need
to make a couple of DeltaV requests:
1. Do a PROPFIND on the public URI to "path" to get the VCC
(version-controlled-configuration) property, which is another
URI.
2. Do a PROPFIND on the VCC URI, and include a 'Label:' request
header with the revision in it, so that your PROPFIND will
actually be directed to the proper baseline. Retrieve the value
of the 'DAV:baseline-collection' property, which is another URI.
3. Append the 'path' portion of your coordinate pair to the
baseline-collection URI. That's the final URI you want.
For an example of this method in action, take a look at
libsvn_ra_dav/props.c:svn_ra_dav__get_baseline_info(). I'm leaving
out a little snafu, which is that the 'path' may no longer exist in
the head revision, i.e. may no longer have a public URI. You can see
how this function compensates for that.
> If I could read a summary then the RFC's would probably be much
> easier to read.
Already committed to notes/. Please feel free to ask questions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 11 19:01:11 2002