obliterate functionality?

[Talden]

>  >> One would expect mirrors with read/write access to fall under the
>  >> guise of the same trusted organization, or else how do you prevent
>  >> someone from checking in random junk into the FreeBSD repository using
>  >> one of the mirrors? Point being, if all mirrors are equal, then they
>  >> should respect each other's obliterate commands.

>  > Mirrors are usually one-way in the FreeBSD world.  They can `read' but
>  > they cannot (and don't really need to) `write' to the main CVS tree.
>  > This means that we are trying to solve the wrong problem, if we spend
>  > too much time worrying about `read-write mirrors'.

>  I was trying to say that when Sun decides to obliterate some file from
>  OpenJDK, the command should get propegated to all their mirrors. People were
>  complaining that they don't want someone (potentially malicious) to be able
>  to propagate obliterate to their machine but I'm arguing that if you're all
>  mirrors you essentially have to trust one another. If you don't trust Sun's
>  obliterate then you're not really a mirror, you're a client. We need to
>  differentiate between the two kinds of repositories.

This seems a reasonable differentiation.  Would a solution similar to
that described below be practical (I don't know the internals of
Mercurial to comment).

The mechanism could be that a obliterate revision is committed that
contains Obliterate imperatives and the revision ids of all affected
revisions.  This new revision documents what the obliterate was and
its scope, it indicates who committed it and, using the usual ancestry
mechanisms, ensures that appropriate obliterates have been applied
downstream.

Obliterated revisions should carry a flag indicating they've been
modified since their hash was computed and contain the new hash (for
validation) and the hash of the obliterate revision (for tracking).

A mirror would always accept and act on obliterate revisions
automatically, a client would not. A client would require using a
command-line flag to force application of obliterates. This gives
'clients' an opportunity to avoid incoming obliterates. If they want
to continue to follow the upstream they'll need to accept the
obliterates but at least this gives the opportunity to clone locally
first.

Any attempt to conclusively solve the 'sensitive material' issue in a
DVCS (or even a CVCS given working copies can be cloned and
disconnected) is a lost cause.  The only practical use of obliterate I
can see here is surgery to remove a number of excessively space
consuming revisions whilst retaining the integrity of the
relationships between distributed repositories.

--
Talden