what if tracker url changes?

[Frits Jalvingh]

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.

This maps
--fixes domui:546 to
to
http://bugzilla.etc.to/show_bug.cgi?id=546

The proper way would be:
1. Do not store status + the URL in the bugs entry but store the alias,
bugID and status (= no indirection used)

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.

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

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.