obliterate functionality?

Paul Moore p.f.moore at gmail.com
Tue Mar 18 10:41:12 CDT 2008

On 18/03/2008, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2008-03-18 at 06:51 -0700, cowwoc wrote:
> >
> > <sigh> Unfortunately, that is a poor assumption:
> > http://blogs.quintor.nl/bbottema/2008/03/01/subversion-obliterate-the-forgotten-feature/
> It's much more than an assumption in Mercurial's case. Mercurial is a
> distributed system and thus, obliteration is generally not possible even
> in theory. Think of Mercurial like a newspaper: if you publish the
> Pentagon Papers one morning, you cannot simply quietly retract them the
> next. At that point, it's no longer a technical issue.

Absolutely, it's not a technical issue. I agree 100% that once a
repository is published and pulled from, you can't put the genie back
into the bottle. However, that cuts both ways - it is both possible
and reasonable to edit history on a purely private branch, before
making it public. To use your newspaper analogy, the editorial team
can pull stories at any time up to publication, and often may need to,
because the content of a story is wrong, libellous, or even just plain
not as important as something that has come in since.

So I'd say that history editing should be possible, but it's not
appropriate for a published repository.

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.

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

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.


More information about the Mercurial mailing list