For Mercurial, having 2 clones can work the same as having 2 branches?

Since I want to diff all the changes I made since 7 or 10 days ago, without seeing the changes of other team members, so I keep a clone, say

c:\dev\proj1

and then I keep another clone that is

c:\dev\proj2

so I can change code for proj1, and then in another shell, pull code from it, and merge with other team members, and run test. And then 10 days later, I can still diff all the code made by me and nobody else by going to the shell of proj1 and do a hg diff or hg vdiff.

I think this can be done by开发者_C百科 using branch as well. Does having 2 clones like this work exactly the same as having 2 branches? Any advantage of one over the other method?

The short answer is: Yes.

Mercurial doesn't care where the changesets come from, when you merge. In that sense, branches and clones work equally well when it comes time to merge changes.

Even better: The workflow you described is exactly the strategy in Chapter 3 of the Mercurial book.

The only advantage of branches is that they have a name, so you have less incentive to merge right off. If you want to keep those proj2 changes separate, while still pushing and pulling them from proj1, give them a real branch. Again, functionally, they're the same.

And yes, this is characteristic of DVCS, not uniquely Mercurial.

Note : I'm more familiar with git than hg but the ideas should be the same.

The difference will become apparent if you update both the clones (which are both editing the same branch) e.g. for a quick bug fix on the integration sandbox.

The right way would be for you to have a topic branch (your first clone) which is where you do your development and another one for integration (your second clone). Then you can merge changes from one to another as you please. If you do make a change on the integration branch, you'll know that it was made there.

hg diff -r <startrev> -r <endrev> can be used to compare any two points in Mercurial's history.

Example history:

       rev      author  description
       ---      ------  ----------------------
@       6       me      Merge
|\
| o     5       others  More other changes.
| |
| o     4       others  Other changes.
| |
o |     3       me      More of my changes.
| |
o |     2       me      My changes.
|/
o       1       others  More Common Changes
|
o       0       others  Common Changes

If revision 1 was the original clone:

1. Revs 2 and 3 represent your changes.
2. Revs 4 and 5 are other changes made during your branch development. They are pulled merged into your changes at rev 6.
3. At this point, to see only changes by me before the merge, run hg diff -r 1 -r 3 to display those changes only.

Why not simply have two branches? (Branching/merging is much easier and safer in a DVCS like Hg or Git than in a centralised VCS like TFS or SVN!) It would be much more secure and reliable.
This will become apparent e.g. when you will want to merge the two branches/clones back together. Also, editing one branch from two different physical locations can easily lead to confusion and errors. Hg is designed to avoid exactly these kinds of situations.

Thomas

As some answers already pointed out, branches (named or anonymous) are usually more convenient than two clones because you don't have to pull/push.

But two clones have the distinct advantage of total physical separation, so you can literally work on two things at the same time, and you don't ever need to rebuild when you switch project.

Earlier I asked a question about concurrent development with hg, with option 1 being two clones and option 2 being two branches.