[RFC] 'bzr-email' using revision_id for threading

[John Arbash Meinel]

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

Robert Collins wrote:
> On Mon, 2008-03-17 at 16:04 -0500, John Arbash Meinel wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I was just discussing this at pycon. But wouldn't it be neat if you
>> could read "bazaar-commits" in threaded mode, and have it trace back the
>> different branches where the commits happened.
>>
>> And then I realized... why not use the revision-id as the "message-id".
>> We are generating the emails ourselves, so it seems like it would work.
>>
>> You could just set:
>>
>> Message-Id: <bazaar-revision-id>
>>
>> And then you set:
>> References: <bazaar-parent-id>
>>
>> I'm going to poke around and see if I can get it to work. But does
>> anyone have an idea about what is legal in "References/Message-ID"?
> 
> I don't think its legal to send two different messages with the same
> message id. Which could happen with multiple announcements. so -1 on
> this, but perhaps the concept can be used somehow still.
> 
> -Rob

Well, reading RFC 2822 says this:

   The "Message-ID:" field provides a unique message identifier that
   refers to a particular version of a particular message.  The
   uniqueness of the message identifier is guaranteed by the host that
   generates it (see below).  This message identifier is intended to be
   machine readable and not necessarily meaningful to humans.  A message
   identifier pertains to exactly one instantiation of a particular
   message; subsequent revisions to the message each receive new message
   identifiers.

   Note: There are many instances when messages are "changed", but those
   changes do not constitute a new instantiation of that message, and
   therefore the message would not get a new message identifier.  For
   example, when messages are introduced into the transport system, they
   are often prepended with additional header fields such as trace
   fields (described in section 3.6.7) and resent fields (described in
   section 3.6.6).  The addition of such header fields does not change
   the identity of the message and therefore the original "Message-ID:"
   field is retained.  In all cases, it is the meaning that the sender
   of the message wishes to convey (i.e., whether this is the same
   message or a different message) that determines whether or not the
   "Message-ID:" field changes, not any particular syntactic difference
   that appears (or does not appear) in the message.

Of specific importance is the last line. If 2 emails were sent with the
same revision_id, then they are arguably the "same message".

If you still feel strongly we could tack on the hostname of the machine
generating the email. It means that when I work on a branch derived from
yours, or switch machines, etc, the threading will break. But for 1
person working on 1 machine they would be preserved.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH3yMkJdeBCYSNAAMRAjaTAJ9rrRR3eA75lAbCaAv8jOTnMSjL6gCggE7U
QDMygodpSIHLCUnfsESM+1k=
=ullL
-----END PGP SIGNATURE-----