Confused repository.

[Rob Landley]

On 12/02/14 06:29, Simon King wrote:
> On Tue, Dec 2, 2014 at 9:02 AM, Rob Landley <rob at landley.net> wrote:
>> I accidentally commited a change on top of another change I thought I'd
>> rolled back, and since rollback won't go more than one back that means
>> my working repository is toast,
> 
> Before I answer your other questions, I should point out that the
> recommended way to fix this would be to "hg update" to the parent of
> the change that you didn't want, and if necessary use "hg graft" to
> transfer the commit that you *did* want into the right place.
> Unfortunately, this will leave a dangling pair of changes in your
> repository, which will cause errors when you "hg push" unless you
> specify which revision you want to push.
> 
> The safest way to remove the dangling changes is to clone your local
> repository using the "-r" switch to specify the revision that you want
> to keep.

Unfortunately dreamhost has a history of leaving old (security pached
but not version updated) software on the server, and I've hit a problem
several times where I cloned locally and then rsynced up a .hg that the
webserver couldn't read because I forgot to init it with
--no-spinning-rims or whatever the new feature was the old thing didn't
understand. And then I always have an hour of tracking down what it was
and fixing it.

(Because my laptop has a copy of the website on 127.0.0.1 and then I
rsync the whole directory up to the server to publish my local changes.
My working directory has .hg as a symlink into the ~/www copy.)

Maybe it's no longer an issue, but about the third time that happened I
developed an aversion to locally cloning something I intend to publish.
(The past couple months Dreamhost has been sending me emails about
updating servers to the 2012 ubuntu release, I should try again...)

> The experimental "evolve" extension provides a cleaner way of doing
> all this - I think you would just run "hg prune <bad-revision>",
> probably followed by "hg evolve".
> 
> http://mercurial.selenic.com/wiki/EvolveExtension

I eventually fixed it by copying a new snapshot of the .hg directory
down from the server, doing an hg checkout in there with it messing
around with working directory files I didn't care about, and then
copying the new .hg into my working directory with all the changes that
needed commiting. That fixed whatever setting it was.

One of the things I've always liked about mercurial is its repository
format is transparent and understandable. This was an instance where I
couldn't find the setting that needed fixing. (Things like .hg/branch
and .hg/cache/branchheads are human readable text... but they all
referenced the _current_ commit, not the weird historical commit it was
stuck on.)

If the answer is "man was not meant to know, install an extension"... I
guess the answer to my question is "there isn't a human readable setting
you could have edited with vi".

>> so I replaced the .hg subdirectory with
>> the one from the website (copying the hgrc file out of it first) and now
>> the repository thinks the "current" version is an old commit from July,
>> even though the .hg directory I cloned from has the newer commits up to
>> yesterday.
>>
>> Where is it getting this information from?
> 
> The "currently checked out revision" is stored in the .hg/dirstate file
> 
> http://mercurial.selenic.com/wiki/DirState

Giant binary blob. I was afraid of that.

Oh well, mercurial having a friendlier repo format than git was nice
while it lasted. (Or at least me not having noticed...)

>> $ strace hg identify 2>&1 | grep '^open(' | wc -l
>>     621
>>
>> Is there any way to do a checkout without changing files in the current
>> directory?
>>
> 
> The command "hg debugrebuilddirstate" can be used to change the parent
> revision of the working directory without touching any files in the
> working directory. As with all debug* commands, you should fully
> understand what you are doing before using it.

I'm trying to fully understand what I'm doing. Unfortunately, I got
spoiled by things like .hgtags being human readable and human editable
(Matt's 2006 OLS presentation was quite convincing). Now I've got to do
the equivalent of windows registry edits instead.

*shrug* Time marches on...

> Hope that helps,
> 
> Simon

It did. Thank you.

Rob