obliterate functionality?

Jens Alfke jens at mooseyard.com
Tue Mar 18 09:49:36 CDT 2008


On 18 Mar '08, at 6:51 AM, cowwoc wrote:

> I have personally run into many of these cases. They might be rare,  
> but I
> strongly advocate that Hg (and others) make it easier to obliterate  
> files
> from the repository so long as you have the necessary privileges.

You simply can't do it in a distributed system. Even assuming you  
obliterated the file or revision from one repository, it's still  
present in any repository that has [transitively] pulled from it. It's  
the same reason you can't "un-send" an email by SMTP, or obliterate a  
web page once it's been cached by Google and the Wayback Machine.

Moreover, in a distributed system it's extremely important to protect  
data integrity against malicious changes, since repositories transmit  
changes to each other, and you can't trust a repository you don't own.  
For that reason, hg (and similar systems like Monotone and Bazaar) use  
digital signatures to identify commits. There is deliberately no way  
to obliterate or alter a prior commit, because it would invalidate the  
signatures of anything that came after it. Basically, obliteration is  
a form of tampering, that has to be prevented.

Hg does have a way to undo the _last_ commit to a particular  
repository. But once that commit has been pushed/pulled to any other  
repo, it's too late.

—Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20080318/fa46285a/attachment.bin 


More information about the Mercurial mailing list