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

Re: HTTP protocol v2: rethunk.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 05 Nov 2008 12:45:11 -0500

Ben Collins-Sussman wrote:
> On Wed, Nov 5, 2008 at 11:22 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>
>> The only big deal is that we won't want to release the peg-less version of
>> your protocol change in 1.6 because it presents a compatibility problem with
>> the now-planned peg-ful version. So, are you committing to the work, or
>> will you be reverting your recent trunk change?
>
> I'll definitely commit to finishing it this week.
>
> But: how is there a compatibility problem? Your p=PEG parameter is
> optional, so I don't think there's any compatibility issue here: we
> could easily ship what I just committed in 1.6, then add an optional
> p=PEG in 1.7. I guess it might end up confusing users down the line
> ("does this server support p= or not?") Maybe that's what you mean?
> I guess I'm sort of operating under the idea that the query string may
> very well expand over time, adding things even beyond pegrev.
>
> But I agree we should add pegrev in 1.6, not 1.7.

No, I meant compatibility problem in the exact same way we saw it in the
Subversion command line, where one day 'svn cat -r4 FOO' meant "Show me the
item named FOO in r4", and then we release a new version of Subversion and
it suddently meant "Show me FOO as it looked in r4, regardless of what it
was named back then".

Now, in retrospect, I wasn't precise in my claim about your recent commit.
So let me clarify that state of things.

Today, the WebDAV BC urls carry a path and a peg revision. We know it's a
peg revision; users don't; users don't really see these things. The
revision is the primary key, the path looked up in the revision.

So, your patch (with 'r=') is either an incorrectly implemented attempt at
carrying a path and a working revision, or a syntactically inconsistent and
functionally lacking way of carrying a path and peg revision (since folks
will naturally think -- and want -- that 'r=' equates with '-r' in the
command-line).

We can go two different ways here:

1. We can say that 'r=' is a peg revision, and have no compatibility
problems in the future. But we do have user confusion, as they'll expect
tha 'r' to mean "working revision" as it does in the command-line tools.
Solution: replace 'r=' in your current code with 'p=' or 'peg='. Folks
won't have the utility they want, but they'll get it when we later add the
working revision ('r=').

2. We can say that 'r=' is a working revision, but the code doesn't treat
it as such, so we have a brand new buggy feature. Solution: Don't do that.

3. We can do (1), and add the working revision support, and make everyone
all smiles and giggles.

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

Received on 2008-11-05 18:45:14 CET

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.