Re: Official revision syntax for Subversion URLs

kfogel@collab.net wrote:

> Sure, people familiar with a repository probably know where it begins
> and ends in the URL. But we shouldn't depend on familiarity, because
> it introduces a "you have to contact a knowledgeable human" step where
> there doesn't need to be one.

This is a powerfull argument against my proposal. Maybe there should be
and a "pro/cons/fix'es database" of approaches before deciding? Here's
something to start with.

There are some places where the revision information could be
consistently placed in an URI:

1. In a query segment ("?rev=1234")

   Pro: Probably easy to implement

   Pro: No naming confusion between files and revision-info (if "?rev="
is used, not "@")

   Con: relative URL's and browsing the repository as a whole with at
other revisions than HEAD (wayback-mode) doesn't work
   Fix: Only use an external (to apache-module) presenter to browse
repository. This is a rather complex task, if links in files with
mime-type text/html are to work (viewCVS?)

   Con: Users opening directories by URL at a revision will, by default,
get a list of files which are present in the revision asked, but the
links in the HTML presented points to files in HEAD (if they exist)
   Fix: Make mod_apache present directory-lists differently

   Con: attaches revisions to files/path's, instead of repositories

2. After the repository name (".../repos@1234/...")

   Pro: Reflects the "subversion philosophy", that repositories have
revisions, not files/paths.

   Pro: Directly allows browsing in wayback-mode

   Con: svn-clients doesn't know where to stick the revision
   Fix: store information about the repository name in the .svn files,
make it available in API "char * repos_of(const char *file_name);" [1]

   Con: users don't know where to stick the revision
   Fix: Interact with user. Possibly time/man-power expensive, but the
user _is_ trying to get a specific version of the repository, not a
specific version of one file.

3. At the beginning of the path ("http://svn.foo/@1234/...)

   Pro: Solves Con's from 2.

   Con: apache-handlers that match URL's are much harder to write.
   Fix: smarter apache handler setup (is this possible for the
multi-repository config of apache-module?)

   Con: URI information wierdly grouped
(http://slog.dk/@1234/~jensen/svn/repos)
   Fix: Stop caring.... [2]

4. Other places?

[1] With other types, obviously... simplified for readability in the mail
[2] Not recommended :)

-- 
Helge
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org