I would like to toss in another potential solution :-)
a. We allow users to access the repository with a query segment
(/repos/file?svn.revision=1234 or whatever)
b. The repository redirects them to a path of a form like /repos/@1234/file
c. The user agent shows that particular content.
The user does not need to know the repository structure in order to get
a particular revision, and the repository does not need to rewrite
content in order for relative links to work. The repository can also
keep whatever its existing syntax for revisions, although it might be
desirable to change it to something which is documented and
user-understood (like the @rev syntax above). This still requires a
network round-trip - although, I think it could be a configuration
option to just serve the file at the original query'd URL for GET requests.
Here's an off-topic question - are there any existing content types
which rely on the query information for rendering user agent-side? In
particular, I'm wondering if something like XForms will fill in a form
based on the values on the URL query. I'm just wondering whether we
would need to process the query or include it in the redirect
-David Waite
SLOGEN wrote:
> 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 :)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 5 23:36:54 2003