Is this right?

[Vincent Ladeuil]

>>>>> "Stephen" == Stephen J Turnbull <stephen at xemacs.org> writes:

<snip/>

    Stephen> But what we want to avoid is a situation where we
    Stephen> make *clients* responsible for tracking *server*
    Stephen> admin decisions.  This just doesn't scale.  So yes,
    Stephen> it's "nice"[1] to make an announcement if you
    Stephen> terminate an URL, but that's not anywhere near
    Stephen> sufficient, and there are already ways to do what is
    Stephen> more important: automatically redirect.

We fully agree there.


    Stephen> Footnotes: [1] And being nice *is* important, BOFH
    Stephen> mythology not withstanding.

Oooh, BOFH ! Long time not read (years), thanks for the reminder :-)

>>>>> "James" == James Westby <jw+debian at jameswestby.net> writes:

    James> On Thu, 2008-11-06 at 09:10 -0600, Brian de Alwis wrote:
    >> Wouldn't Russel's problem have never occurred if bzr instead  
    >> remembered the originally-specified branch name, 'lp:bzr-xmloutput'?   
    >> If bzr remembered both the original name and the mapped name (as a  
    >> cached value), then bzr could fallback to the original name should the  
    >> mapped name fail.

    James> I was in a meeting with Mark the other day, and he
    James> suggested pretty much this, but for a slightly
    James> different use case.

    James> If bzr remebered what the user asked for and what they
    James> got then when a branch disappeared or diverged it
    James> could use tell the user some scenarios for what may
    James> have happened and ask them how they would like to
    James> proceed.

    James> I do not know what the UI for this would look like.

    James> Also, there would be performance implications for some
    James> of the cases, and to work out what was going on bzr
    James> would have to do the equivalent of "missing" on an
    James> extra branch or two, just to flesh out an error
    James> message.

    James> Exploring some of the implications and trying to come
    James> up with a design would be interesting though.

Without going that far as remembering the url pointed by the lp:
url and the lp: url itself ; simply keeping the lp: url and resolving
it when needed would have indeed solved Russel's problem.

I was (and still am) in favor of such a behavior but it was
objected that lp: urls are not "real" urls and as such should not
be stored as-is in bzr config files.

That may need revisiting in light of these discussions.

     Vincent