Relative URLs in externals definitions. Yes, again.

Some time ago (Jan 24, 2005), Max kicked off a thread recommending a
format for relative externals definition sources. (See thread here:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=281739)
This is the last thread mentioned in issue #1336 around this topic.

In summary, Max proposed the following:

   Existing absolute external:

      http://svn.collab.net/repos/svn/trunk/subversion

   Relative form 1: Scheme-relative (RFC 2396 compliant)

      //svn.collab.net/repos/svn/trunk/subversion

   Relative form 2: Host-relative (RFC 2396 compliant)

      /repos/svn/trunk/subversion

   Relative form 3: Repository-relative (Fill void in RFC 2396)

      ///../svn/trunk/subversion

   Relative form 4: Directory-relative (RFC 2396 compliant)

      ../../svn/trunk/subversion

Discussion ensued, with Max defending his proposal.

Then came Greg "Party Pooper" Hudson (Hey, he said it himself!) who
expressed disinterest in trying to stick with RFC 2396, and (like some
others) preferred to introduce some sort of syntax that made explicit
the relativity of the path ("using keywords like "site", "repos", and
"scheme" at at the beginning of the externals"). Some others agreed,
one mentioned the new RFC 3986, but ultimately the thread sorta died.

Another idea that can be picked out of the thread is that whatever
scheme we choose, the command-line client should be able to also use it
during its argument processing. Makes sense to me.

It's, uh, sorta frightening that as long as issue #1336 has been around
(since May 26, 2003!), we've not been able to agree on something here.
The *implementation* of relative URLs in externals is probably a
no-brainer at this point, especially since working copies have been
storing repository root URLs for some time. There's even a patch in
the issue that proports to work (for some definition of the scheme).

So the question is, can we get past this UI debate and get this
feature into Subversion 1.5 or not? I am volunteering to compose or
shepherd the code into the codebase to implement whatever scheme we
choose. But we do have to choose one.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand