Fix a botched log-message

[Stefan Monnier]

>> > There are some complications that I'm aware of.
>> 
>> > 1) Do you version this new information or not?
>> 
>> I'd expect we would want to version it.
>> 
>> 
>> >    b) If you do version, then you still have a potential for conflicts
>> >    on a location that doesn't have a direct filesystem representation.
>> 
>> Why not give it a file name.
>> After all, we do it for .bzrignore.  We could do the same for tags, BTW.
>> That would mean we can't change that info on a tree-less branch, but
>> it doesn't sound like a serious restriction.

> Stefan's answers are what I had in mind.

> This is obviously not suitable for the nuclear scenario, but it is a
> much smaller and more appropriate hammer when you just discover a
> typo.  If you really need to destroy the data creating new revisions
> is better.

Actually, it may also be a solution to the nuclear scenario, if you
spice it up a bit: e.g. not only the .bzrloginfo file is used by
`bzr log' but it is also used by Bzr to retroactively change the
comments in the repository.  This wouldn't work in Git where changing
log-comments would change the ID of a commit, but for Bzr this might be
workable: it means there can different log comments for the same revid,
depending on which repository you ask, but that's about it.

So if the log-amendment is in the .bzrloginfo file of revision 3245,
any repository that merges this revision will have its log comment
updated, and checking out an older revision will either give you the old
or the new comment depending on whether the repository already has
merged 3245 or not.

But this is much less lightweight.  Also it may not work at all,
depending on internal details with which I'm not familiar.


        Stefan