{{toc numerate=1}}
1. ##clone## the **??(blue)master??** repository twice
2. **??(green)main??**
3. **??(red)sync??**
1. **??(green)main??**: ##pull## changes from the **??(blue)master??** repo
1. **??(green)main??**: ##commit## your your changesets to default tip or branch (5.0 | 4.3)
1. **??(red)sync??**: ##pull## changes from the **??(green)main??** repo - get the new commits you want to push
1. **??(red)sync??**: ##pull## changes from the **??(blue)master??** repo - checks for new commits in the repo
1. **??(red)sync??**: ##rebase## your changesets to repohead if necessary
1. **??(red)sync??**: ##push## your new local commits to **??(blue)master??** repo head or branch
Do not force a commit (will cause a branch). Avoid the risk of causing multiple heads.
%%
% hg push
pushing to https://bitbucket.org/wackowiki/wackowiki-dev
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)
%%
====Step-by-Step====
Use two clones. Do all your work in clone "**main**", and all your merging and pushing from clone "**sync**". Let's say the main repository is "**master**", and your two clones are "**main**" and "**sync**":
file:/main_work_synch_repo.jpg
To get set up, either ##clone## the **master** repository twice, or, you can ##clone## your **main** locally, but be sure to update the "parent" reference in your **sync** clone such that it points to the **master** instead of your working clone (I do that by copying **main/.hg/hgrc** to **sync/.hg/hgrc**.)
Here's the workflow:
1. As before, work in **main**. Edit files at will, and check in logical changesets as needed.
1. When you want to ##push## a changeset, go to your **sync** clone, and ##pull## your new changesets from your working clone:
%% % cd ../sync
% hg pull ../main && hg update%%
At this point, it's best to try a build/test as well, to make sure changeset is complete. If you're working on many things in parallel, it's possible that your changeset is depending on a change in a file you haven't checked in yet.
1.#3 Now ##pull## in the new changes from the **master**, and merge these:
%% % hg fetch %%
(Or if don't have the fetch extension installed, do it manually - ##hg pull && hg merge && hg ci -m## "Merge").
1.#4 If something went wrong with the merge - no problem. You can just go and nuke the entire **sync** clone and try again! Your modified files, and your new changesets, are still sitting completely unaffected in the **main** clone. Just ##clone## **sync** again and try more carefully :)
1.#5 Now you can ##push## your merged changesets to the **master** repository:
%% % hg push %%
1.#6 ...and now you can ##pull## these changes back into your **main** repository:
%% % hg pull ../sync && hg update %%
This will give you all the tip changes into your **working** clone, but without the risk of causing multiple heads that you have to merge. You've already merged your local changesets over in the **sync** clone, and therefore there is no conflict between your local changesets and the new changesets in the tip!
This process may seem tricky, but it's trivial once you try it:
**Work in main, push and merge in sync, and pull back into main.**
Finally, I want to call attention to item **#4**. Doing it this way means that it's trivial to try again if something wrong happens during the merge. I've had a couple of merges where I've really mucked things up. Unfortunately, this was in my tree that contained the changesets that I cared about. In the end I had to go and manually copy out the files I wanted to check in and try again. With the above approach, if something goes wrong, just nuke the **sync** clone and try again.
This is the reason I'm suggesting this approach to anyone using Mercurial, not just people who want to work with edited files. Especially when you're new to distributed version control systems or Mercurial, it's great to be able to go back if you make a mistake. Just make sure you know what you're doing before you submit that final ##hg push## command to push everything back to the **master** repository!