ANN: edit_message plugin

[John Arbash Meinel]

Alexander Belchenko wrote:
> Aaron Bentley пишет:
> 
>> DOING THIS IS A MODEL VIOLATION.  YOU ARE LIKELY TO BREAK BZR.
>>
>> The revision id refers to all the metadata, including the commit
>> message.  If you do this, you MUST change the revision id of the
>> revision you alter, and change the revision ids of all its descendants,
>> AT MINIMUM.
> 
> 
> 
> I really want for someone comment my plugin -- thank you.  And I want to
> understand your caution.
> 
> Right now revision id automaticaly generated by function in
> bzrlib.commit module named _gen_revision_id(). This function accept 2
> arguments: `config` and `when`. From `config` extracted user email and
> when used as timestamp. Plus at the end added 8 random bytes. Probably I
> miss something, but I don't see how commit message affects to revision
> id. What I do wrong?
> 

The specific issue is that when I merge from you, the only thing I check
is if my revision ids match your revision ids. I don't check the text, I
don't check anything else (yet).

If our revision ids match, then I assume we have the same information.
You are breaking that model by having a different set of information
attached to the same revision id.

Back when we actually verified sha-1 hashes, bzr would have faltered
after your change. (The sha1 sum would be different). We removed that
because of upgrade requirements, and introduced testaments, but we
haven't fully integrated them to provide integrity again.

In the short term, what will generally happen is that if anyone has seen
your revision, they will never get the new text, so it doesn't really
help anyway.
In the long term, it could create 2 revisions with different hashes,
which will cause bzr to complain all over the place. Say we store
revisions in a weave, and you modify one of them, now the two weaves
will have different hashes for the same revision id, and the trees won't
be mergeable, probably not what you want.

The best thing for you to do is only allow you to modify the *last*
commit, by uncommitting it, modifying the text, and creating a new
commit. This can get all of its information from the old commit.
If you really wanted to fix an old commit (say 5 commits ago), you could
pop off the last 5, fix the commit, and then create new commits based on
the other ones.

If you follow some of the Cherrypicking threads, there might be some
future work to have a new revision-id superceed an old revision-id,
while indicating the contents were 'similar'. I don't know if that will
bear fruit or not, but that is a similar idea. Wanting to change
history, and indicate to other branches that they should preferentially
use *this* history.

Its funny, this came up fairly often in Arch, too. I don't know of any
other SCM that lets you change the commit messages (I think there was
one, but I can't remember it), but because it seems like the message is
right there, everyone wants to just fix it. You are definitely not alone
in this. I think in my early days (of Arch) I might have done it, and
I've definitely seen many people attempting it.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060125/751579a2/attachment.pgp