How to use Mercurial?

[Jim Hague]

On Thursday 08 Apr 2010 15:51:42 Jon Ribbens wrote:
> If we want to make sure a project repository has all the latest
> changes from the central repository, we do 'hg pull -u', which
> then requires a 'hg merge' and 'hg ci -m merge'. However, if
> the working directory is dirty this involves all sorts of nastiness
> with 'hg merge -f' and manually keeping track of which changed files
> are changed due to the "pull -u" and which were already changed
> locally.
> 
> This is obviously a mess. How are you *supposed* to use hg in this
> circumstance? So far, 'cvs' (which we were using before) is winning
> - 'cvs up' just Did The Right Thing without complaint.

The core of the problem here is that merge, which will be necessary if you've 
made a commit in the local repo which isn't in the central repo (and so the 
pull creates an extra head). Merges have to happen in the working directory, 
in case fixups are needed, and be committed. It's the price of being able to 
commit locally and be distributed. I tried explaining this in more detail in a 
little paper I wrote which tries to explain what's happening with a DVCS, and 
why at times it doesn't respond like a CVCS - 'Inside a distributed version 
control system', http://www.lunch.org.uk/articles/Hg.pdf

Personally, if I really need to get a central update into my working dir while 
working on a change, I use the MQ extension to turn my current change into a 
patch, pop that patch off the MQ stack, do the update, and then push the patch 
back into the working dir:

$ hg qnew -f my-change
$ hg qpop
$ hg pull -u
$ hg qpush

From that point, I'll use MQ to finish the work on the patch, so make the 
occasional

$ hg qrefresh -e

and when it's done I'll turn it into a pukka change with 'hg qfinish'.
-- 
Jim Hague - jim.hague at acm.org          Never trust a computer you can't lift.