correcting old log messages

[Stuart McGraw]

Alexander Belchenko wrote:
> Stuart McGraw пишет:
> | I have another question about something I do in
> | CVS now, but don't see a way to do with Bazaar
> | and that is to change commit (aka log) messages.
> |
> | Often I will notice, long after the fact, that in
> | a commit message I made a typo, or the message does
> | not clearly explain a change, or is just plain wrong.
> | In CVS, it is easy to simply edit the repository
> | file(s) to change an old log message.
> |[...]
>[...]
> But actually it's the wrong path, because Bazaar
> is decentralized and distributed system and
> you may end with the state when some branches
> of your project still used old&wrong commit messages
> and some branches will use new&corrected ones.
> 
> It's just the way to disaster.
>[...]

OK, I can see that, but...

[I realize that the following, coming from someone
with 2 days of experience with Bazaar, is pretty
audacious, I hope you'll cut me a little slack.

I don't see that having branches with differing
history metadata, or at least metadata like commit
messages that are for human consumption and aren't
used to control bazaar's operation (as opposed to
metadata like dates which might), must necessarily
lead to disaster.  The working and committed files
differ between branches too, yes?  That's what merge
is for.

Suppose that bzr did allow me to change the commit
message of some ancient commit.  There is probably
no reason to keep a history of such metadata changes
as these are corrections, not versioned changes (c.f.
my distinction between changes and corrections below).
So bzr could simply change the message in my branch
and record the timestamp of the change.

When your branch and mine are merged, bzr notices
the difference in commit messages and asks the merger
which he/she wants to keeps, defaulting to the newer.
As with other changes, policy for acceptance would
vary depending on the merger.  Changes going into
some official repo would be closely scrutinized.
changes coming from such a repo might be accepted
unquestioningly.

I have no idea how Bazaar works internally so perhaps
something in Bazaar's design or implementation would
prevent doing this, but is it hypothetically reasonable?

I know very little about SCM but I have built a few
database apps that required auditing (who changed
what data when).  I discovered pretty early that I
had to distinguish between changes (that get audited,
or versioned in SCM terms) and corrections (that don't).
Failure to do so can often make the history record so
noisy with non-significant changes that in the worst
case, it becomes nearly useless.
And the difference between corrections and changes
also depends on the environment -- any mis-information
that was long lived enough to have affected decisions
may want to be treated as a change rather than a
correction, keeping the tradeoff between useful
information and noise in mind.

Again, I apologize for proposing to long-term users
and developers how to do things.  These are just some
of my thoughts, stimulated by what I see as a problem
(inability to correct bad data) and if I'm clueless,
please feel free to tell me. :-)