obliterate functionality?

cowwoc cowwoc at bbs.darktech.org
Tue Mar 18 10:37:18 CDT 2008

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

	Couldn't you do the following?

1) Node1 obliterates a file which Node2 has already pulled but Node3 has 

2) The file is flagged "obliterated" and its underlying data is removed 
from the disk (on Node1).

3) When Node3 tries pulling changes from Node1 he gets the "obliterated" 
flag but no data to go with it.

4) When Node2 tries pulling changes from Node1, his copy gets 
obliterated as well (assuming he hasn't modified it, otherwise a 
conflict arises). When Node2 tries pushing changes to obliterated data 
on Node1 a conflict arises.

	Isn't that technically possible?

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

	I understand, that but this isn't what I'm asking for.


More information about the Mercurial mailing list