5

I have a central Mercurial repository containing a history cloned from a SVN repository using hgsubversion. I have pulled the additional commits made to the SVN repository since the original hg repo was cloned; these are currently in the default branch.

I also have a named branch. I have cloned this branch (using hg clone -b mybranch) to my local system. Now I want to grab the changes that exist only in default and make them available in my named branch. The obvious way I see to do it is to do a hg update mybranch on the repo, then hg merge default and commit. This seems perilous--if I forget to update back to default after I'm done, all future pulls from SVN will pull changes into mybranch.

I have also considered that perhaps I should not have specified mybranch when I cloned the repo, but cloned the entire repo and just updated to mybranch locally. Thus I could pull the changes in default to my local clone and do the merge there.

What's the right answer here? Do it on the shared repo and just be careful? Clone everything and manage branches locally? Or is there an easier solution I'm missing?

Tim Keating
  • 6,443
  • 4
  • 47
  • 53
  • 1
    Merging seems just perfect, I don't really get your problem. *hgsubversion* appears to be aware of SVN branches, so when you pull, it should put *SVN-trunk* changes into your *default*, and *SVN-mybranch* into your *mybranch* branch. If you merge and stay on *mybranch*, does the tip of *mybranch* really change if the remote side has trunk-only changes? Pulling should work independent of the revision of your working copy. – Oben Sonne Jan 20 '11 at 21:48
  • My concern was with making direct changes to the master repository, and the associated risks therewith. Of course, in the DVCS world, all repos are essentially equal, so it's probably just my client-server VCS bias. – Tim Keating Jan 21 '11 at 19:22

2 Answers2

6

In general with Mercurial, anytime that I do something that I think might cause issues, I clone the repo and try it out there. Then I can either choose to push those changes back in or perform the action on the real repository. Either way I have the option of failing and not causing any damage. Clones can be thrown away, you don't have to keep them around if you screwed up.

Aaron Weiker
  • 2,523
  • 2
  • 21
  • 22
  • 1
    That is a fine point, and it's the answer I was leaning toward anyway. I just wanted to make sure there wasn't some feature of hg I was missing, and that seems unlikely, given the firehose-like response rate to most of the SO questions I've posted. – Tim Keating Jan 21 '11 at 19:19
1

Do it in the shared repo and be careful. Or clone the entire shared repo, do the merge there, and then push to the branch-only clone.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169