[RFC] history editing vs history presentation

[Maritza Mendez]

On Mon, Jun 8, 2009 at 11:12 PM, Robert Collins <
robert.collins at canonical.com> wrote:

> 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.


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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090609/c163271a/attachment.htm