Excellent summary, Greg, thanks for doing this.
My votes: #2 (perhaps as a post 1.0 feature), and #3a. More specific
notes below.
Greg Hudson wrote:
>
> THE PROBLEM: Not totally clear. But that's never stopped us before.
>
It's not really an existing problem--it's about making Subversion even
better--and enough people are trying to do enough different things with
direct URL access that there should be some decision on a standard way
of doing it.
> A. We know from the past that some people want to be able to
> HTTP-browse their repositories at particular revs without
> installing ViewCVS, but there isn't full agreement that we want
> to wander in the direction of providing more browsing
> functionality.
>
I think if you choose a good URL scheme, you get this automatically--web
browsers will already know what to request. This may not be the most
important reason, but it's a huge convenience, especially for business
users/consultants (which I am), who want to be able to grab a single
version of a single file from a computer with no other clients
installed, without the authorization scheme limitations/additional
overhead of ViewCVS.
> B. konqueror developers seem interested in adding a URL which means
> "visit a Subversion repository resource at rev foo using HTTP,"
> although it's not clear whether that functionality is
> Subversion-specific or DeltaV-specific. Adding information to
> http: URLs won't really help to solve this problem because
> visiting an http: URL already means something to web browsers.
>
This is huge. This essentially provides direct operating system access
to the full repository from within ordinary user applications. Suddenly
every KDE application automatically becomes a (limited) SVN client, at
least for being able to retrieve previous revisions of a file.
And KDE is just one potential client--another is the ability to create
some custom web service to interact with the repository in highly
flexible ways. Define a URL syntax, and people can then build such
applications, saving the overhead of starting a shell and whatever other
overhead the CLI subversion client requires, and accessing the specific
repository version directly. I'll concede that I know nothing about
Delta V, and that may be a better way to go about it, but the sheer
convienience of manipulating a URL directly, rather than having to query
the server, get REPORTS and whatever before you can construct a query
for the resource you want seems awfully appealing.
> C. It's possible that we might want to amend or change commands like
> "svn co" so that you provide revision numbers with URLs instead
> of with the -r option; in this case we'd also need to amend the
> syntax of file: and svn: URLs, and possibly amend the syntax for
> specifying working copy directories.
>
Seems appropriate to support for "svn co", but I don't see why you'd
specify working copy directories any differently.
> THE SOLUTIONS:
> 2. Add something to the end, whether it's "?rev=REV" or ";REV" or
> "@REV" or "@@REV" or "@@/REV".
>
> Issues: Relative browsing breaks (i.e. relative HTTP URLs within
> Subversion documents will produce URLs which don't include the
> version component.) Creates complexity when paths actually end
> with something which looks like a trailing version component.
> Conceptually backwards, since a pathname can indicate a totally
> different resource (node) at different revs, not just different
> content.
>
+1 here--but with an implementation that rewrites the URL to #3a.
Rewriting the URL makes relative browsing work, and changes the path to
something that is conceptually correct. I think we should specify that a
query built this way returns the node at the revision specified,
changing the path as appropriate. This provides an additional
feature/capability that I think would be great. I think if this is
specified now, it can be implemented post 1.0.
(my vote is ?rev=REV)
>
> 3a. Add something to the middle for all URLs, including ones for the
> head. (http://host/repos-location/fspath becomes
> http://host/repos-location;/fspath) Makes explicit the
> separation of repository and repository content.
>
> Issues: Big change. Adds ugliness when you want to use
> Subversion to revision-control a web site.
>
Should be easy to support for clients--just like #2, rewrite the URL
when you return the resource. But I'm confused by the issue you
state--if you use Subversion to revision-control a web site, wouldn't
this approach make it more flexible? As long as links are allowed to
omit the revision marker, defaulting to HEAD, this shouldn't have any
effect on web development.
> 6. In addition to one of #2-5, migrate to or add a URL syntax which
> doesn't start with http: so that a browser knows to interpret the
> URL to possibly include a (possibly svn-specific) DeltaV revision
> traversal on the resource. "svn+http:" was the specific
> suggestion, although that would hardly be the ra_svn protocol
> tunneled over HTTP.
>
> Issues: Big change from current way of thinking.
>
I brought up the svn+http: syntax, but I didn't mean there to be any
change for Subversion. The kioslaves Mickael described just need to have
some unique protocol so that KDE can choose which one to use to access
Subversion repositories. I think we should just suggest that syntax to
Mickael (and others) specifically for implementing similar types of
functionality--but I see no reason we would want to change the current
protocols. These are more implementation-specific ways of
differentiating a Subversion repository from a web site from an ordinary
file in the file system from any other input source--if you're using a
real Subversion client, use the appropriate existing protocol.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 6 20:46:50 2003