Mercurial wipes repository history!?

[Jon Ribbens]

On Thu, Apr 08, 2010 at 10:47:21AM -0500, Matt Mackall wrote:
> On Thu, 2010-04-08 at 15:54 +0100, Jon Ribbens wrote:
> > It is in that log, yes. It was not in the scenario we were trying to
> > replicate. It is also not at all clear to me that "clone" should be
> > a roll-backable operation (it is evidently not clear to the hg authors
> > either, since a local clone is not roll-backable and a remote clone
> > is.)
> 
> One uses the internal transaction mechanism (one big pull), and one
> doesn't (directory tree copy). It's that simple.

It's fairly obvious why there's a difference, yes. However it seems to
me that the fact that there is a difference is an implementation
detail that should be hidden from the user "behind the scenes".

> To lose file data with rollback, you have to have first destroyed it
> somewhere else, because transactions all involve copying. For instance:
> 
> hg clone --pull a b
> rm -rf a
> hg rollback -R b
> 
> hg commit a  # copy a into history
> rm a
> hg rollback
> 
> ..which is why the documentation says "use with care". Apparently, we
> need to make that more prominent somehow.

I suppose my two main points are that (a) trying to rollback a clone
should fail, because what it currently does can be VERY surprising and
is never useful, and (b) if 'hg rollback' just printed a summary of
what it *would* do, and then 'hg rollback --yes' or something actually
did it for real, then I think that would be a useful improvement. That
might make it a bit inconsistent with other 'hg' commands, but then
it's already inconsistent in that it potentially destroys data and
it's not undo-able.