1

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 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?

nonopolarity
  • 146,324
  • 131
  • 460
  • 740

5 Answers5

6

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.

Andres Jaan Tack
  • 22,566
  • 11
  • 59
  • 78
  • 2
    The development of Mercurial itself is done using the model of separate repositories for the development and stable branches, supposedly. In the beginning of Mercurial, that was the _only_ model, and the developer didn't see a need to change after the introduction of named branch support. – Binary Phile Nov 05 '10 at 15:21
  • Yeah, ignore the folks suggesting named branches. This is the way to go. – Ry4an Brase Nov 06 '10 at 02:06
  • I'm one of the folks suggesting named branches. If you ignore me and you encounter the following problem, fie on you! The problem with clones is that they are lightweight. You get into the habit of cloning from the master, cloning your workspace into a second, removing the first workspace, etc. If you accidentally delete a workspace that had unique changes, too bad. Whereas if you use named branches, you can push those changes in to other clones - the master, your own. Etc. I.e. NAMED BRANCHES MAKE YOU LESS LIKELY TO LOSE WORK because it can all be kept consistent in replicas. – Krazy Glew Jul 21 '12 at 03:00
  • Haven't you ever stared at a directory that contains dozens of project clone repos in differeht states,and wondered "What the heck is each of these clones all about?" Or been tempted to rm -r some-repo, to realize, too late, that it had changes you wanted to keep? Yes, you can compare repos. But with branches, they all live in one logical place. // i.e. you can easily lose a cloned repo, or lose track of them, whereas with branches they live in one logical place, but possibly replicated physically. – Krazy Glew Jul 21 '12 at 03:08
  • My typical workflow is: // hg clone project-master my-local; hg clone project-master working-repo1; cd working-repo1; edit; hg push my-local; cd .. // hg clone project-master working-repo2; cd working-repo2; edit; hg push my-local; cd ../working-repo1; edit; hg push my-local. etc. // If the work is done on branches it does not interfere in my-local. And you only have one repo that you *must* not delete, my-local. – Krazy Glew Jul 21 '12 at 03:15
1

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.

Noufal Ibrahim
  • 71,383
  • 13
  • 135
  • 169
1

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.
Mark Tolonen
  • 166,664
  • 26
  • 169
  • 251
0

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

Thomas Weller
  • 11,631
  • 3
  • 26
  • 34
0

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.

Community
  • 1
  • 1
Geoffrey Zheng
  • 6,562
  • 2
  • 38
  • 47