what if tracker url changes?

[Martin Pool]

On 18 November 2010 11:06, Frits Jalvingh <jal at etc.to> wrote:
> Hi Jelmer,
>
> The "level of indirection" is *already* present- I do not propose
> another one. I would just want it somewhere else at the very least. The
> existing code maps an alias to an URL (= existing level of indirection)
> at commit time, using a per-user locally, manually (and of course often
> wrongly) specified mapping in bazaar.conf.

There is a ton of theory about URLs, but basically they are a string
that specifies where a given resource can be found.  One could argue
we should instead store a URN
<http://en.wikipedia.org/wiki/Uniform_Resource_Name> that identifies
the bug we're talking about, but not how to reach it.  We could have
something like urn:launchpad.net:bug:1, and
then at run time discover/decide how to reach it.

(I kind of expect Robert to pop up at this point.)

This would be somewhat cleaner than storing URLs, though perhaps
mostly in a theoretical sense.  When people want to uniquely identify
a project, they tend to use at least domain names, or something that
hangs off them.

My sense is that common practice does lean towards using URLs.

If you want to store URIs there is nothing about the bzr
implementation that would stop you.  I would even happily look at a
doc patch that suggests you can do that.

> 2. Map this to the required usage when it is needed, /using a mapping
> inside the tree/ (versioned properties, .bzr-meta/config, whatever).
> This file would then create a mapping to the display URL for log
> (required usage=display), and can be easily extended to handle other
> functions for the tracker (like sending a fixed-in SOAP request to the
> tracker, for instance).
>
> I am actually making multiple points here:
> 1. Storing the URL is bad because it does not present the bug data in a
> "normal" format, to use for multiple functions.

<https://launchpad.net/bugs/1> is not quite normalized; I guess the
tuple (launchpad.net, 1) is more normal.

> 2. The tracker URL at some point is not a reasonable thing to
> version-control. The bug solved is.

It's a bit of a tradeoff against making it selfcontained.

> 3. The current method of storing the URL mapping per user in combination
> with translating this at commit time leads to a design blunder: an
> incorrectly configured user can now commit wrong bug URLs (we tried, it
> works) that become part of immutable history.. If you really, really
> need to map this locally (which you should not) then please map the URL
> at DISPLAY time, not commit time (i.e. store alias and bug#, and
> translate it at bzr log time). This way at least you can fix alias spec
> errors without uncommit et al. If you want to be compatible store the
> URL /in addition to/ the alias+bug, but please replace that URL if a
> different mapping is present at "bzr log" time.
>
> 4. But of course the only right way is to store the mapping is as
> versioned data, so we're sure /all/ users use the same config, and we're
> able to change that config in a (version) controlled way.
>
> I think there's lots of use-cases for having versioned properties...
> This is a (less important) one. Having the rules file as versioned
> properties is of prime importance.

It's a classic case of data that changes over time, but not
necessarily on the same timeline as the versioned data.  If you look
at an old tree, and the bugtracker has moved, you probably still want
the new url rules.

The basic mechanism here is translation of the stored bug ids before
they're used.

If users are inserting the wrong data, then I do think the main thing
that is needed is
 - standard configuration of the rules which control what is stored
 - perhaps a reasonableness check for the bug ids they enter

-- 
Martin