Simple question on TortoiseHg

Say one cloned a repository and his main job is to edit it locally. What is the proper operation to follow so that he can just merge with the initial upstream while keeping his changes? i.e. like 'Update' in TortoiseS开发者_运维知识库VN.

The short answer is "pull". From there, you have two options

You can either simply update, exactly as you would with svn, and your changes will remain local and non versionned, or you can commit and merge your changes with the head you pulled. If you don't push back, those merges will never appear on the central repo, and you will have the extra benefit of having your changes versionned and easy to track. The second method is much more in the spirit of DVCS.

The two methods in @Axelle Ziegler's answer are the age-old "rebase vs. merge" duel.

The first method requires more explanation.

To start off, all DVCSs encourage frequent commit, which is one major advantage over CVCS like svn, so your local changes are (should) probably already committed when you want to sync with upstream. If you don't commit, hg update by default will try to merge your changes into the revision you're updating to. See hg help update for details (note: be VERY careful with -C).

Now if you do have local changesets when you pull upstream, you'll get two heads (no not you, but your repository). Then you must decide whether to merge or to rebase.

hg prefers and encourages merge, so rebase is provided not in core, but with a bundled extension that you have to enable to get the command.

There have been many good questions and answers here on the topic. If you like to cut to the chase, read the links in this blog to see what the Creators said.

There's hardly any "simple" question when it comes to DVCS :)

I see a third solution with the "mq" extension ("Mercurial Patch Queue").

Using this you wouldn't commit, but just create and furthermore refresh your patch(es) from your local changes. After pulling on a regular basis and prior to updating your working copy, you would detach your patch(es), update and then re-attach the patch(es).

This way you will manage your own changes completely isolated in the Patch Queue, while keeping on touch with the changes from the world.