On Mon, Jun 8, 2009 at 11:12 PM, Robert Collins <<a href="mailto:robert.collins@canonical.com">robert.collins@canonical.com</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> So, I wanted to make several different RFC's to get discussion going about this. But I think the issues are not sufficiently teased out yet. In part, I hope to tease out the issues here and perhaps end up with some suggestions about what we should aim to have to provide a good mix of effective tools.</blockquote><div> This a most articulate and comprehensive summary of the case for "history editing." I am sure this will help keep the complicated discussion in focus. Disclosure: I am one of those people who prefer not to use history editing. What I mean by this is the potential abuses of history editing outweigh the benefits for my team. I say this even though I have been greatly tempted to edit commit messages for profanity or misleading info. But I resist the temptation because it is a slippy slope. Yet I recognize that there are other legitimate uses for history editing and I respect the opinions of people who want to see this in bzr. I would ask that the following ideas be considered in the discussion if possible: 1. Allow bzr-init to set a non-revocable policy (property of a format) when a branch is created about whether (and what kinds) of history editing will ever be allowed on that branch. This sounds simple but might not be. Checkouts would have to inherit from their parents I think, and successively unbinding and rebinding might cause ugly edge cases. 2. Treat the history editing as a kind of meta-history which is 100% auditable. The default behavior of all bzr commands could be to show the history-as-edited but history-aware commands would have new options to display the "true" meta-history along with the edited history. </div></div>FInally, I would simply remind that some of us work in environments where auditability is a serious requirement. No system is perfect in ths way. But if it can be shown that a system can be easily subverted to conceal or misrepresent actual events -- even if the intent is honorable -- then some organizations may not be able to use it for some jobs. Either of the above suggestions (or maybe a better idea) which gives users the *option* of preserving auditability would be very helpful. Sincerely, Maritza