Comment 4 for bug 210142

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.