what if tracker url changes?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/18/2010 04:37 PM, Frits Jalvingh wrote:
> On Thu, 2010-11-18 at 13:53 -0500, Aaron Bentley wrote:
>> On 11/18/2010 12:50 PM, Frits Jalvingh wrote:
>> We want to be able to identify bugs unambiguously.  We want any person
>> who looks at a revision, to be able to see what bug it fixes.  So
>> identifiers relative to a specific tracker don't help.
> 1. You do not help them in case the tracker has changed URLs.

We have a globally unique identifier-- we just need a way to map it to
the appropriate resource.  This problem is no worse than we would have
with any other globally unique identifier.

> 2. Why does a tuple [tracker GUID, bugID] not uniquely identify a bug?

It does.  Such a tuple is, itself, a globally unique identifier.
(Provided bugID is unique with respect to the GUID.)

>>> especially since the tracker ID is not created by Bazaar at all:
>>
>> Neither are email addresses, which we also use as globally-unique
>> identifiers.  In both cases, we are delegating the assignment of
>> globally-unique identifiers to external sources.
> Different discussion, and again- where is GUID-ness of email addresses
> needed? To uniquely identify users?

Yes.

> You clearly don't- 

We do.  For example, on Launchpad, we use the user ID to connect
revisions to user accounts.

> it depends on what he enters as whoami.

Similarly we depend on user configuration and input for bug IDs.

> Of course you can hope it is unique- and we
> can have the same hope for a tracker GUID.

Indeed.  That's what I meant by "best-effort".

> Please remember that I have no problem with "preferring some globally
> unique ID" related to the bug- I just want bug ID and tracker GUID
> separate, and lookup for tracker url-for-a-specific-action configurable
> independent of it.

When you said "separate" earlier, I didn't understand that a tuple of
(GUID, bug-id) would satisfy that requirement.

>> Bazaar generally does not attempt to provide the guarantee that an
>> identifier is the only one that identifies a resource.
> That is not the issue. It would be nice if it IS a correct
> representation if you're using an URL.

It seemed like you were making it an issue.  In any case, you seem to be
suggesting that a GUID + bugID combination which, by itself, has no
intrinsic meaning is superior to a URL, which has an intrinsic meaning,
because that intrinsic meaning may become stale.  For myself, I think
the URL is superior - that some intrinsic meaning is better than none -
but I can understand that others might feel differently.

>>> - it's key would/should change if the tracker URL changes.
>>
>> Similarly, email addresses also change.  Would you change how user-ids
>> are handled also?
> Is there a clear use case where that is needed? Does an email address
> consist of multiple parts, like tracker and bug number?

Sure.  Email addresses usually contain an @ symbol that separates the
identification of the user from the identification of the domain.

> So- no. There is no problem we /can solve/ around this.

Just as URLs can change, email addresses can change.  We could solve
this by providing a way to map old email addresses to new addresses,
just as we could provide a way to map old URLs to new URLs.

>>> If you want to have the ability to have some unique "key" representing
>>> this then just represent the bugtracker instance itself with some unique
>>> key and separate the bug ID from it.
>>
>> We cannot separate the tracker from the bug id.  We don't have a way of
>> identifying the bug if we do that.
> I don't get that. A compound key is unique too.

I did not get the impression that you were talking about a compound key.
 I got the impression that you were talking about storing only the bug
id, and having the bugtracker be implied by the branch, or perhaps by
local configuration.

>> We want there to be no ambiguity about what bug is being referred to.
> Well, it would at least be ambiguous when a tracker URL changes. It
> would be less ambiguous if that could happen without the internal
> representation (guid+bugid) having to change.

I don't see using a URL as significantly worse than using an arbitrary
GUID.  Both can be transformed into a usable URL.  A URL has the
advantage of being meaningful most of the time without needing to be
remapped.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzlxzQACgkQ0F+nu1YWqI1pMwCePCVOMSU0Otta7DDpBNZtGZQi
EWMAnRb6YEz8k6nSqAL3JbxltOoL36O4
=WmMs
-----END PGP SIGNATURE-----