Morten Ludvigsen <morten_2ps_dk@yahoo.co.uk> writes:
> > Yes there is. This behaviour does not belong to the defined interface
> > and so is implementation specific. Because of that this may change
> > for implementation reasons in the future and all your applications
> > relying on that behaviour will break.
>
> OK - so the behaviour as it stands today is subject to change. Let me see if
> I understand you correctly:
>
> 1. The ability to get a file in a given revision using an HTTP GET on some URL
> will always be there.
>
> 2. The way this URL is constructed may change.
> Today it is "[URL-to-repository-root]/!svn/bc/[revision]/[path]".
> Tomorrow it might be different.
>
> What I do not understand is why it would not be a good feature to have. In my
> case it would certainly be extremely useful and the functionality is already
> there.
There's a deeper issue here beyond "why don't we just add this
feature?"
The issue is that we use WebDAV/DeltaV as our network protocol.
mod_dav processes every request to the svn <Location> in the context
of this protocol. You're suggesting that we add a new feature whereby
some kind of specially-formatted GET request still travels through
mod_dav and ends up a "special case" in our server code... the whole
feature would be outside the deltaV protocol.
Personally, I can understand the desire for this. A friend of mine
once asked, "do we control our network protocol, or does it control
*us*?" I wouldn't mind inserting this special-case. Another part of
me sort of cringes, though, in adding non-deltaV stuff to
mod_dav_svn. We're trying to *increase* interoperability, not
decrease it.
Another option, of course, is to write a tiny C program or python
script (or something) which actually behaves like a good deltaV
client: it makes a few GET requests and uses the proper procedure to
"discover" the URL, exactly as libsvn_ra_dav does. For example:
$ get_bc_url.py 2319 http://svn.collab.net/repos/svn
http://svn.collab.net/repos/svn/!svn/bc/2319/trunk
Then you could paste that URL into your web browser, keeping in mind
that it might be different from server to server, or day to day.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 14:54:20 2002