3

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!

Improve this question

2 Answers 2

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Great - this is all helpful information. So basically, your advice is to only use the command 'hg pull -u' on the secondary repos? It will be hard for me to choose which one will be the main one, since machine 1 is something like my work desktop, machine 2 is my home desktop, and machine 3 is my laptop (which i only use on the go).
I have almost exactly the same setup and treat my work desktop as the "main" repo. You can push and pull between all 3 repos w/o creating branches as long as you keep them in sync before committing any changes. And even if you don't merges really are not a problem.
3

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

Improve this answer

2 Comments

Thanks for the tutorial link.
@astromax : as said by fred, a handy solution is to dedicate one machine to hold the master repo (it is just an organizational choice). On this one, no sync is need. On the others, always hg pull -u. It doesn't hurt : if there is nothing new, nothing will happen. And before leaving one machine, hg push.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.