0

I'm studiyng Mercurial but I don't understand how it detects the file conflicts.

When a centralized SCM (as SubVersion) detects a conflit between two versions of a file in my project, it means the version number of mine local file is minor then version number of same file in the remote repository, because another developer (p.e. John Smith) has committed before me (by the same initial version number).

In a decentralized SCM (Mercurial, Git, etc), I haven't a central repository, then:

  • I clone a repository, downloading a number version A of file from the remote server;
  • John Smith clones the same repository, downloading the same number version A of file from the remote server;
  • John Smith codes a little and commit in him local;
  • After, I commit in mine local;

How Git understands that our files are direct descendant from number version A? The Mercurial/Git/Bazaar/etc has'nt an internal number what identifies: how they understand when a modified file is in conflict or not?

alepuzio
  • 1,382
  • 2
  • 28
  • 38
  • On DVCS every repo clone has the full history log on it, so it always knows who is the parent of a file. – MGP Jul 05 '13 at 15:37
  • This may help. http://mercurial.selenic.com/wiki/UnderstandingMercurial – MGP Jul 05 '13 at 15:38
  • I've given an answer, but I feel that questions like this are better answered on the Mercurial mailinglist: mercurial@selenic.com. There you find the Mercurial developers and you can ask followup questions. – Martin Geisler Jul 06 '13 at 09:10

2 Answers2

2

Any conflicts are only detected after you and John Smith communicate with each other (using hg push and hg pull) and one of you then want to merge the two lines of work (using hg merge).

After you pull the change by John Smith into your local repository, the changeset graph might look like this:

... [a] --- [b]
       \
        `---------- [c]

where you made changeset b and John Smith made c, both based on changeset a. Between a and b, you changed the file helloworld.c and between a and c John Smith changed the same file. Mercurial is now able to tell that there might be a potential conflict here (an overlapping edit) and it will tell you when you run hg merge.

The system is not based on version numbers associated with the files — it's based on the above changeset graph. Concretely, when you merge b with c, Mercurial will find the greatest common ancestor, which is a. It will then look at the manifest (a list of the files (and their version) present in a given changeset) in a, b, and c and notice that the file helloworld.c existed in three different versions. That tells Mercurial that it needs to do a three-way merge with a being the base version, and b and c being the local and other versions. By default, it tries to do the merge internally, but it will call external merge tools (like KDiff3) if that fails.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
0

If you really want to know how it works I recommend Chapter 4 of the book "Mercurial: The Definite Guide"

In short, Mercurial creates a unique identifier for each version. It is unique across all repositories - based on hashing. Both you and John Smith will have the same identifier for version A in your repositories. Your local changes will have different identifiers. When one of you decides to pull and merge changes, Mercurial is able to determine that both of you made changes to the same version A. Both changes are compared to base version A. It is easy then to check if resulting patches are conflicting or not.

Slawek Rewaj
  • 809
  • 8
  • 16