Re: Relative URLs in externals definitions. Yes, again.

Ben Collins-Sussman wrote:
> On 11/29/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>
>> 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.
>
> Can you elaborate on this? Give examples?

Well, I'd have to dig thru the archives again for specifics, but I
recall there being a proposal to support something like 'svn switch
R//branches/issue-1336-dev', where that 'R//' bit is magic that means
REPOSITORY-ROOT-URL. (If you want details, I can dive back into the
archives -- but then, so can you.) Anyway, if the command-line support
that kind of thing, it would makes sense for externals definitions to
support them, too. In other words, there's value in consistency between
these two "relative URL" UIs.

(I've no opinion on specific syntax proposals, nor complete knowledge of
all the proposals that have been floated on the topic.)

>> 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).
>
> Well, I think this is one of those things where designing the
> interface is probably 80% of the work, so we shouldn't feel too bad.
> We've always been very careful about defining elegant interfaces that
> are as simple as possible, and careful to avoid feature bloat. That's
> a hard standard to keep up. :-)

Oh, I'm certainly not interested in damaging Subversion's attention to
quality and long-sightedness. And if the 80/20 rule was in effect here,
I'd not be making a fuss. But at this point, designing the interface
has been 99.98% of the work. :-)

And feature bloat doesn't really appear to be a concern here. There are
established use-cases for all points on the proposal (as far as I could
tell), and it all appears to come at a really low maintenance cost
(we're talking about string parsing and path manipulation here).
Meanwhile, we've been hearing routine complaints about this missing
feature for over three years, which is especially hard for users to
choke down when there's already a working patch for some level of support.

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