obliterate functionality?

[Ezra.Smith at bentley.com]

The rogue repository thing is exactly the case I'd be concerned about.
Currently, if unwanted changesets make their way into the distributed
system, you can do a backout or revert and propagate them through the
system to fix it. It's much harder if the offending changesets are
"obliterate" changesets that destroy files. 

I think of it like a layered cake. If someone comes along and adds
another layer to your cake, you can remove it. You might have to touch
up some frosting again to make everything look good, but you can still
make it work. It's subtractive, and you have everything you need to get
back to your original state. On the other hand, if someone comes into
the room with a hammer and pounds your cake into oblivion...the recovery
is going to require a whole lot of baking.

Unless, of course, you've backed up the things that were destroyed.
Again, I could always use Mercurial to version control my original
Mercurial repository before pulling, to make recoveries easier...but
that just seems silly.

I also like the newspaper analogy a lot. You can post retractions with
Mercurial. You can send out a backout changeset that says "No, sorry, I
was wrong. This was a bad idea." But you can't scrub the idea from
people's heads once they've seen it. 

-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:55 AM
To: mercurial at selenic.com
Subject: Re: obliterate functionality?



Jens Alfke wrote:
> 
> For that reason, hg (and similar systems like Monotone and Bazaar) use

> digital signatures to identify commits. There is deliberately no way  
> to obliterate or alter a prior commit, because it would invalidate the

> signatures of anything that came after it. Basically, obliteration is

> a form of tampering, that has to be prevented.
> 

Okay, I am beginning to understand. So you're saying that all data
associated with a commit is signed with a public key and that removing a
file from within that commit would require one to re-sign the data
somehow
and that isn't possible. Correct? I agree this is a tough problem to
solve.
I'll give it some more thought.

What happens if I pull updates from a rogue repository that corrupted or
removed some of my files? Sure I can check out versions prior to this
"bad
commit" but ideally I'd like to undo pulling those changes. What would
one
do in such a case? I assume that Hg lets you obliterate entire commits
as
opposed to individual files...?
-- 
View this message in context:
http://www.nabble.com/obliterate-functionality--tp16114445p16124275.html
Sent from the Mercurial mailing list archive at Nabble.com.

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