Mercurial Log Graph Complications

Question

Okay - I'm definitely learning a lot about Mercurial and version control systems more and more as I use them, but I'm really confused about why my local copies of one of my repositories (call it project-alpha) on three machines I use (machine 1, machine 2, and machine 3) are different. Notably, they do not share the same tip.

I was hoping somebody could explain this to me, and in addition offer some explanation as to how I may avoid having to "merge" branches altogether (which is how this complication came up in the first place). It would be awesome if somebody could provide an example of how certain circumstances will force me to "merge" on one machine, whereas on another it is perfectly fine without.

For clarification, I am including the

hg log --graph

commands for each of the three machines I am using (but only where they begin to differ, since it's a long project I'm working on).

Machine 1

@  changeset:   88:e8aafce5753a
|  tag:         tip
|  user:        Your Name <>
|  date:        Mon Jan 06 15:30:15 2014 -0500
|  summary:     
|
o  changeset:   87:5d76250aad71
|  user:        Your Name <>
|  date:        Mon Jan 06 11:32:53 2014 -0500
|  summary:     
|
o    changeset:   86:4788926f4dc9
|\   parent:      84:caf2a2a127e0
| |  parent:      85:682beb5c2a22
| |  user:        Your Name <>
| |  date:        Thu Jan 02 12:52:17 2014 -0500
| |  summary:     
| |
| o  changeset:   85:682beb5c2a22
| |  parent:      83:bde4e46678d8
| |  user:        Your Name <>
| |  date:        Thu Jan 02 12:38:45 2014 -0500
| |  summary:     
| |
o |  changeset:   84:caf2a2a127e0
| |  parent:      82:729da698a926
| |  user:        Your Name <>
| |  date:        Tue Dec 17 15:44:17 2013 -0500
| |  summary:     
| |
| o  changeset:   83:bde4e46678d8
|/   user:        Your Name <>
|    date:        Wed Jan 01 22:20:54 2014 -0500
|    summary:     
|
o  changeset:   82:729da698a926
|  user:        Your Name <>
|  date:        Mon Dec 16 12:41:54 2013 -0500
|  summary:     

Machine 2

@  changeset:   88:e8aafce5753a
|  tag:         tip
|  user:        Your Name <>
|  date:        Mon Jan 06 15:30:15 2014 -0500
|  summary:     
|
o  changeset:   87:5d76250aad71
|  user:        Your Name <>
|  date:        Mon Jan 06 11:32:53 2014 -0500
|  summary:     
|
o    changeset:   86:4788926f4dc9
|\   parent:      83:caf2a2a127e0
| |  parent:      85:682beb5c2a22
| |  user:        Your Name <>
| |  date:        Thu Jan 02 12:52:17 2014 -0500
| |  summary:     
| |
| o  changeset:   85:682beb5c2a22
| |  user:        Your Name <>
| |  date:        Thu Jan 02 12:38:45 2014 -0500
| |  summary:     
| |
| o  changeset:   84:bde4e46678d8
| |  parent:      82:729da698a926
| |  user:        Your Name <>
| |  date:        Wed Jan 01 22:20:54 2014 -0500
| |  summary:     
| |
o |  changeset:   83:caf2a2a127e0
|/   user:        Your Name <>
|    date:        Tue Dec 17 15:44:17 2013 -0500
|    summary:     
|
o  changeset:   82:729da698a926
|  user:        Your Name <>
|  date:        Mon Dec 16 12:41:54 2013 -0500
|  summary:     

Machine 3

o  changeset:   89:e8aafce5753a
|  tag:         tip
|  user:        Your Name <>
|  date:        Mon Jan 06 15:30:15 2014 -0500
|  summary:     
|
o  changeset:   88:5d76250aad71
|  user:        Your Name <>
|  date:        Mon Jan 06 11:32:53 2014 -0500
|  summary:     
|
o    changeset:   87:4788926f4dc9
|\   parent:      83:caf2a2a127e0
| |  parent:      85:682beb5c2a22
| |  user:        Your Name <>
| |  date:        Thu Jan 02 12:52:17 2014 -0500
| |  summary:     
| |
+---@  changeset:   86:eab05f7f7ab6
| |/   parent:      83:caf2a2a127e0
| |    parent:      85:682beb5c2a22
| |    user:        Your Name <>
| |    date:        Thu Jan 02 12:52:31 2014 -0500
| |    summary:     
| |
| o  changeset:   85:682beb5c2a22
| |  user:        Your Name <>
| |  date:        Thu Jan 02 12:38:45 2014 -0500
| |  summary:     
| |
| o  changeset:   84:bde4e46678d8
| |  parent:      82:729da698a926
| |  user:        Your Name <>
| |  date:        Wed Jan 01 22:20:54 2014 -0500
| |  summary:     
| |
o |  changeset:   83:caf2a2a127e0
|/   user:        Your Name <>
|    date:        Tue Dec 17 15:44:17 2013 -0500
|    summary:     
|
o  changeset:   82:729da698a926
|  user:        Your Name <>
|  date:        Mon Dec 16 12:41:54 2013 -0500
|  summary:     

Let me first start off by saying that I understand there are some differences simply due to the fact that some changes were pushed on some machines and pulled on others. Machine 1 and 2 are the primary ones I use, and it clearly doesn't differ too much. What I'm concerned about is Machine 3, which currently has 3 heads, and an additional changeset (89 instead of 88). I'm a bit confused as to what is happening, how I can fix this, and I would appreciate knowing exactly what I did to cause this so that I may avoid this type of behavior next time. Thanks in advance!

Answer 1

I only see one extra head on machine 3, namely changeset 86:eab05f7f7ab6.

This is the supernumerary changeset, and you can notice it has the exact same parents than common changeset 4788926f4dc9. So I guess it comes from a merge explictly done on machine 3, before pulling the repo already containing a merge (requested on another machine some seconds earlier !).

That answers one of your questions : once you've merged on one repo, you don't need (and shouldn't) do it again on the others. Any duplicate task is suspicious and defeats the purpose of a VCS.

You can reduce branching, and thus the need to merge afterward, by :

• Getting the habit to update to the last revision (hg pull -u) before you start to work.
• Using mq, which I discourage until you are confortable with standard usage of mercurial.

Last advices, you must provide commit messages, and read twice and a half this smooth tutotial

Answer 2

Don't confuse hg numbers with the actual version number of the change. (i.e. change 88 in one repo is not the same as change 88 in another repo unless they have the same signature code. The log numbers are a handy short cut for referencing changesets in a single repo, but do not translate across repos ).

It's going to be next to impossible to avoid merges if you have 3 different repositories. Generally hg does a reasonable job with auto-merging. If you set up a decent hgmerge to use your favorite 3 way diff setup, even the occasional manual merge is not that painful.

However, if you want to avoid merges as much as possible you'll need to pick one repository to be the "main" repo and have the other repos push and pull from the main repo.

The first step for any work on the secondary repos is to sync to the main repo.

hg pull -u 

Any changes you commit must be relative to the tip on the main repo or you will create a branch that needs to be merged to have your changes made to the main repo.

hg incoming 

is very useful for monitoring the state of remote repos.

One of the main reasons to use a distributed version control system is that it makes merging much less painful. Merging is just a part of "standard" workflow and if you commit and sync often merges should not be much of a problem.