obliterate functionality?

[cowwoc]

Talden wrote:
> 
>>  >> 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
> 

This sounds good to me. Furthermore it is my understanding that users who
are interested in solving the "sensitive material" problem find it
sufficient to obliterate the data from the official repository. There is no
expectation to prevent delete sensitive material that already got downloaded
by some 3rd party.

Is it possible to implement the above scenario in Mercurial?

Gili
-- 
View this message in context: http://www.nabble.com/obliterate-functionality--tp16114445p16194043.html
Sent from the Mercurial mailing list archive at Nabble.com.