obliterate functionality?

Ezra.Smith at bentley.com Ezra.Smith at bentley.com
Tue Mar 18 12:53:08 CDT 2008


I don't feel particularly safe about letting other people choose when
data in my repository disappears, even if it was my choice to pull from
those people to begin with.

I suppose I could start double version controlling, so when someone
destroys a changeset that I wanted to keep, I can restore it...

But in all seriousness, it's a good feeling to know that pulling is a
non-destructive operation. It's the kind of foundation you can build a
very stable source control system on top of.

-Ezra 

-----Original Message-----
From: mercurial-bounces at selenic.com
[mailto:mercurial-bounces at selenic.com] On Behalf Of cowwoc
Sent: Tuesday, March 18, 2008 11:46 AM
To: mercurial at selenic.com
Subject: Re: obliterate functionality?



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-fo
rgotten-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?



>> 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.
-- 
View this message in context:
http://www.nabble.com/obliterate-functionality--tp16114445p16123856.html
Sent from the Mercurial mailing list archive at Nabble.com.

_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial



More information about the Mercurial mailing list