Log comments cannot be changed/edited/annotated

This is more of a feature request than a bug, but it could still be useful functionality.

It would be nice to be able to add/modify a bug fix on an old revision. Can this not be done in similar fashion that tags are handled?

Maybe these "changes" (comments that were modified, and fixes that were added etc) can be propagated by doing an update (on a checkout) and doing a merge on a branch.

In the case of merge, an option to include/exclude these changes can be given:
bzr merge <this> <other> --only-new-revisions
where --only-new-revisions will exclude the "changes" that was made to older revisions

Should these changes be versioned? If not, then this feature might give someone the power to mess a branch up (well atleast the branch's revision properties (--fixes) and messages. And what happens if 2 people change the same revision at the "same"
time? Also, it sounds like if an old revision supports properties "changes" then it would need its own mini branch.

Still this feature has been requested by our build manager, so I hope it would be possible in the future to modify messages and --fixes properties on a old revision.

If changes to old revision metadata were associated with new revisions like described in the original approach, that would mean some additional bzrlib API: you wouldn't simply ask for "the commit message of revision 435", but instead you'd ask for "the commit message of revision 435, as seen from a branch with tip 3260" or similar. Same for fixes, and probably date and author as well. I guess a new optional parameter could probably take care of this, with the default returning the unmodified original message. bzr log and friends could be moved to that API quickly, other apps might be slower. Therefore differet apps might have different opinions about what the metadata of a given commit looks like.

Another problem I see with this approach is collisions - people doing modifications "at the same time". The current bzr conflict handling is based on files in the working tree. To leverage that, it might make sense to reify the commit messages and other meta-data as files as well. Wasn't there some discussion about a .bzrmeta directory? One problem with these files would be that changes should always be recorded relative to the original message, while it would probably be overkill to store a file for each and every commit message, and also problematic to use the revision id in the name of such a file before the commit associated with that revision id. So simply treating these as normal files would probably not be enough. Still, I think a file-based approach has probably better chances than completely new collision handling or unversioned changes.

I think putting them into a structured file in .bzrmeta would be
fairly appropriate: that's transparent and doesn't need major surgery,
and could be done from a plugin. Normally we ask the repository for
revision data so you'd need to make sure that perhaps a wrapped
repository is seen when the branch is opened.

--
Martin <http://launchpad.net/~mbp/>

Crucial use-case:

When attempting to push a branch into a Subversion repository that has a commit hook that requires an issue tracking ID for work that was done in Bazaar 'on spec' without a known issue ID, the commits to Subversion will be rejected. Unless the issue ID's can be added retroactively, there is no way to commit to Subversion unless you're willing to lose the entire history.

I did figure out how to hack Bazaar to let me commit my changes with a prepended tracker issue ID. Basically, I just hacked plugins/svn/push.py, line 162 of Bazaar 2.3.0 to prepend "ID-123: " to each commit.

This is nasty little hack, but it worked well enough to allow me to push the entire history to our repository. I'm not going to bother to figure out how to make a switch to provide an option for this because I think it could have some unintended consequences if used on a large scale, especially for merging back down from such a hacked repo. So, I just added this note for prosperity in the off chance that it may help somebody else.