cowwoc at bbs.darktech.org
Tue Mar 18 10:46:09 CDT 2008
Matt Mackall wrote:
> On Tue, 2008-03-18 at 06:51 -0700, cowwoc wrote:
>> <sigh> Unfortunately, that is a poor assumption:
> 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
>> the repository tree) and more flexible to be usable. Imagine Apache
>> 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.
More information about the Mercurial