A tale of user-friendliness with "hg merge" and "hg rollback".

[Adrian Buehlmann]

On 12.10.2009 23:23, Rob Landley wrote:
> Ubuntu 9.04, 64-bit.  But I think I've figured it out.  My bash command history 
> for that window says:
> 
> hg clone http://landley.net/code/firmware
> cd firmware
> ls
> hg rollback
> hg log -v | less
> 
> Repository was gone at that point.
> 
> I'd forgotten I did this in a fresh checkout of the repository (in an attempt 
> to make that weird not-quite-there uncommitted merge commit go away).  The 
> rollback didn't trim off the last commit in the repository, it apparently undid 
> the _clone_.  (Which was not the behavior I expected, but I suppose makes 
> sense in retrospect.)

[..]

Granted, Rob made errors.

Possibly stupid follow-up side question: why should a 'hg clone' that
succeeded be rollback-able at all?

Compare local:

$ hg clone -U x y
$ cd y
$ hg rollback
no rollback information available

with remote:

$ hg clone -U http://bitbucket.org/abuehl/hgext-cifiles hgext-cifiles
real URL is http://bitbucket.org/abuehl/hgext-cifiles/
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 2 changes to 2 files
$ cd hgext-cifiles
$ hg rollback
rolling back last transaction
$ ls
<nothing>

The purpose of 'hg clone' is creating a valid repository (one that passes
hg verify).

Rollback is supposed to bring a repository back to some previous state.

But an empty directory is not a valid repository.

Couldn't we say that for any repository X where hg verify succeeds and
where we can do a hg rollback on X, a later 'hg verify' should succeed
too? (the 'verify invariant').

But 'hg verify' fails on an empty directory.

$ mkdir a
$ cd a
$ hg verify
abort: There is no Mercurial repository here (.hg not found)!


Ultimate question: shouldn't 'hg rollback' fail with

   no rollback information available

for each and every successful fresh clone, no matter from
where it was cloned?