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

[Kevin Bullock]

On 13 Oct 2009, at 4:10 PM, Adrian Buehlmann wrote:

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

I'll let others answer this one, but...

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

A clone-then-rollback doesn't leave an empty directory, nor an invalid  
repository:

$ hg init test-repo
$ cd test-repo
$ echo foo > foo.txt
$ hg ci -A -m 'add foo.txt'
adding foo.txt
$ cd ..
$ hg clone --pull test-repo cloned-repo
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd cloned-repo/
$ hg log --style compact
0[tip]   bd3bf3d2bd00   2009-10-13 16:33 -0500   kbullock
   add foo.txt

$ ls
foo.txt
$ hg rollback
rolling back last transaction
$ ls -A
.hg/  foo.txt
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
0 files, 0 changesets, 0 total revisions
$ hg log --style compact
$

It leaves a repository with no changesets. But your 'verify invariant'  
holds.

Pacem in terris / Mir / Shanti / Salaam / Heiwa
Kevin R. Bullock