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

Summary: URL rev proposals

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-08-06 19:30:14 CEST

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

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.