obliterate functionality?

[Matt Mackall]

On Tue, 2008-03-18 at 11:37 -0400, cowwoc wrote:
> 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 
> not.
> 
> 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?

Sure. But first, who's allowed to do it? There is no central authority.
SUN does not have the authority to broadcast obliterations of the
changes in my OpenSolaris branch, and I don't have the authority to
obliterate theirs. Though it might be fun to try to obliterate some
security fixes.

Second, such a flag basically says "HEY EVERYBODY, THE INFORMATION
YOU'RE NOT SUPPOSED TO HAVE IS RIGHT HERE!" even though it may be
written as "(please kindly pretend you never saw this)". 

Lastly, there's no way to enforce such a flag.

-- 
Mathematics is the supreme nostalgia of our time.