An Example of Mercurial Being a Distributed Version Control System
We internally use mercurial as the source version control system.
Mercurial is a very useful and powerful source control system, the difference
from cvs/svn is that, mercurial is a distributed source control system, see
its official doc for more information about this feature.
Today I ran into a very interesting situation: I have a hg repository R on a server S,
and I cloned two copies from it, one is also on S, let’s call it B; The other on
my PC, let’s call it C. And I didn’t know that I actually cloned C from B, rather
than R, as how people usually worked. I could do so because mercurial is a distributed
version control system, each copy of repository has enough and all information about
the entire repository of the group.
However, I could do hg pull/hg commit/hg push in C, though I have been doing so to
B rather than R, and it is OK, as explained above. And I sometime later discovered
this situation when I did “hg pull -u” on B, believing B’s working copy would be
updated from R since I had already pushed to R from C, but B wasn’t updated.
Then I realized my repo address in C may be wrong, and yes, it was not R but B.
Then, I did “hg commit” followed by “hg push” in B, the two actions pushed all
changes which were committed by C into B, into R this time. And since B already had the
changes in its local repo, I can do a “hg update” to update its working source,
so that now B’s working source also have the latest code.
And then I update C’s repo address to use R instead, then all C’s commits goes to R, and
I can do “hg pull -u” in B to update B’s local repo and working copy, as
people normally work.
That is to say, any mercurial repository can be a central repo, for other
repos to do hg clone, hg commit or hg push; each local repo is equal to the central repo,
all repos including the “central” repo are working as identical and equal peers,
rather than working in a “client/server” mode like cvs, where clients can’t be
a server. Actually this “central” repo is only put there for ease of use in a group, the
group can work well if that “central” repo was some group member’s local repo;
I think the above situation is a vivid example of mercurial’s being a distributed
source control system.
PS:
1. Another important thing to note:
Although we can apply a patch generated from “hg diff” using the GNU patch utility, instead
of using hg import –no-commit, hg import –no-commit sometimes can not be replaced
by the GNU patch utility. For example, when a patch involves a change made by
“hg add”, “hg remove” or “hg rename” commands.
When applying such a patch to the working source code, we must use “hg import –no-commit”,
otherwise, the change may not appear in the working source directory.
2. We need to set the following to our local repo’s .hg/hgrc file:
[diff]
git = 1
Without the above setting, when you do “hg rename F”, the changes generated simply
consists of the changes which would be generated by “hg remove F” followed by “hg add F”.
Such a change is not only lengthy, but also confusing.
With the above setting, the “hg rename” command won’t be generating such stupid changeset,
it simply marks the file F’s name has changed, only two lines in the changeset.
最近评论