obliterate functionality?

Marcin Kasperski Marcin.Kasperski at softax.com.pl
Wed Mar 19 07:50:35 CDT 2008

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

IMO not so. Obliterate should be local operation. Wanna obliterate?
Ask all clones to do it. You can't? That means you can't truly
obliterate, some will keep. Bad luck but if that's the problem of ISO
in repo it need ot harm that much.

So IMO the point 4) above is

4) When Node2 tries pulling changes from Node1, the obliterated file
is treated as if it were 'hg removed' on Node1, plus some
warning/message is displayed with suggestion to obliterate it. Also,
there could be some command (or maybe flag of the obliterate command)
which would show whether there are files remotely obliterated in the
current repo.

PS I feel that one could hunt for common technical means while
analysing a) obliteration and b) partial clones. Both are about
not-copying and not-containing some parts of the history....

| Marcin Kasperski   | Systems built by humans are always subject
| http://mekk.waw.pl |          to human error. (Parnas)
|                    |

More information about the Mercurial mailing list