obliterate functionality?

[Matt Mackall]

On Tue, 2008-03-18 at 15:41 +0000, Paul Moore wrote:
> Whether you want to attempt to include technical safeguards to
> minimise the risk associated with the social problem (for example,
> warning on such commands) is a judgement call - but you can't solve a
> social issue with technical solutions.

If I see the obliterate command in the command list, I will file it in
the back of my head as "it's relatively easy to recover from leaks". I
don't ask on the list about it and I don't think about the implications
of every user having a cryptographically robust copy of the history.
Then when I've made such a leak (more likely because I'm not aware of
the dangers), I will now be very disappointed to realize that no, it's
in fact basically impossible to quietly retract my data.

Having obliterate print a warning would be like having an "unsend"
button in your email client that brought up a dialog box saying "you're
joking, right?" It's a trap.

> > > Subversion also lets you export and re-import but this is a cop-out in my
> > > view. This needs to be a lot faster (especially if the files are leaves in
> > > the repository tree) and more flexible to be usable. Imagine Apache having
> > > to take their repository offline for an entire day while they obliterate
> > > files, it's simply not an option.
> >
> > Now imagine Apache having to hunt down every single user who pulled from
> > them around the world and coerce them into destroying their private copy
> > of the Apache history.
> 
> On the other hand, imagine Apache accidentally committing something
> that simply must not be published (proprietary code, personal data,
> password information, whatever). If damage limitation (by getting rid
> of the offending material as fast as possible) isn't possible, what
> can they do?
> 
> > It is possible to remove stuff from an official repository, it's just
> > not easy. Pretending there's a simple single-command safety net is
> > unhelpful. It just encourages people to make mistakes.
> 
> Making it a complex multi-step operation, in damage-limitation cases,
> simply encourages a different class of mistake.

I'm not making it a complex multi-step operation. It inherently is one.
We have to shut down the repo, modify the history in some fashion (mq or
reconversion), then deal with the fact that changing one commit in the
past has changed the signature of every successive commit in a way that
disagrees with every user out there. That means purging every mirror and
asking everyone to purge their private copies (we definitely wouldn't
want them pushing the samizdat changeset back to us!). The history
editing itself will usually be relatively easy.

> There's no perfect answer. There are simply trade-offs which may or
> may not suit a particular potential user. You're saying that if
> obliteration is an important feature to someone, then they should look
> for an alternative to Mercurial. That's fine. But it's not an absolute
> requirement for a DVCS, just a design decision Mercurial has made.

Yes, we've designed the system such that no one can easily modify
history. Because a DVCS has no central authority, the alternative was to
allow everyone to easily modify history. Whether such a system would
actually work, I can't say. But I certaintly wouldn't trust it in the
real world.

-- 
Mathematics is the supreme nostalgia of our time.