[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Older versions through http-repository browsing

From: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2005-03-04 22:53:44 CET

On Fri, 2005-03-04 at 13:10 -0800, Greg Stein wrote:

...

> But, as we discussed in IM, there is a middle ground here. While we still
> don't want to expose "!svn/bc/NNNN/" in any way (in case we need to change
> it later), we *can* expose "!svn/rev/NNNN/" and just define that tree as a
> revision tree for *servers* to use.
>
> Note that I say servers. Clients cannot assume that path construction. Any
> given server might change the "!svn" portion.
>
> But for rewrite tools, CGIs, etc, it is quite possible to build a tool
> around ".../rev/NNNN/". Since the CGI or other tool is installed by the
> server admin, who also controls the special URI prefix, then they can all
> be coordinated.
>
> The changes to mod_dav_svn should be minimal. In repos.c, there is a
> special_subdirs[] array. Copy/paste the { "bc", ... } section and rewrite
> it to "rev". That should be it. If we ever need to change the "bc" stuff,
> then it will get more complicated, but until then, the two are precisely
> the same.

I'm still -1 on declaring support for this URL style as a "public API",
for the following reasons:

1. It's a feature that is currently available with Subversion add-ons
(ViewCVS, etc).

2. It would need to be carefully documented.

3. As Mark Phippard just discovered, using the URLs with the svn client
"works", but always returns the HEAD revision (in his example, he tried
'svn cat http://svn.collab.net/repos/svn/!svn/bc/1000/trunk/README') and
the results were unexpected. So the moment we decide to suppor the
above URL style as Public API, we'll need to fix that bug. And even if
we document that this URL style is *only* for use in web browsers,
people *will* use it with the command-line svn. I think it will cause
confusion.

Basically, I'm asking folks to think very carefully about any new
features that we add to core Subversion (and yes, declaring this as
public and supported *is* a new feature) as there is a cost to doing so
beyond just the minimal fix to repos.c that Greg mentioned.

-Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 4 22:54:41 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.