I think this thread is about ready to wind down, so I'll summarize
what I've seen, for the sake of people who didn't have time to follow
it.
THE PROBLEM: Not totally clear. But that's never stopped us before.
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.
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.
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.
THE SOLUTIONS:
1. Do nothing for now. Has some popularity at the moment.
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.
3. Add something to the middle, between the location of the
repository and the fs path.
Issues: Given a normal HEAD URL, one can't algorithmically
determine where to add revision information. Creates complexity
when locations of repositories end with something which looks
like a trailing version component (but that's not necessarily
unreasonable).
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.
4. Add something to the beginning. Non-starter from an Apache
configuration viewpoint; the web server doesn't know that the URL
refers to an svn repository unless it begins with the location of
such.
5. Add something to the second-to-last path component (which might
be the last path component of the repository location).
5a. Add something to any single path component.
Issues: Confusing and ugly. Quoting problems can't be solved by
sticking something onto the end when you want to interpret a
path literally.
5b. Add something to any path component; if multiple revs are
specified, actually interpret that by traversing the nodes
specified by the partial paths. ("Go to the directory node
given by /a/b at rev 10, traverse that node was to rev 5, and
from there go to c/d.")
Issues: Much too complicated.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 6 19:31:18 2003