views:

81

answers:

2

I have the following situation:

  • I have site A, which has it's Mercurial repo, and we've been developing it for a while. Let's say A has had 5 revisions.
  • We now has to create Site B, which is almost identical to site A, except for graphical design, mostly. So I cloned the repo, started site B, and now B's repo has all of A's history, plus a bunch of changesets that should never go back to A (mostly CSS and images). Let's say these changes took me 3 revisions.
  • Finally, I've now made a change to B that I would like to move back to A because it belongs on both sites. This is revision 9 in B's repo.

The question is: How can I move revision 9 from B's repo into A's repo, without also moving revisions 6-8?

  • I've tried regular pushing/pulling, but that moves all the changesets.
  • I've tried exporting bundles or patches, but those refuse to import in A because of the missing parent.

I thought one of the beauties of DVCS was that I could do this kind of thing easily (which in the "centralized" VCS world I could fix easily with branches and merging, I've done it with Vault a lot and it's pretty easy).

Am I missing something here?

NOTE: I looked into "MQ", but that seems to be a big can of worms, and it looks like it'll affect the regular commit cycle just for being enabled. Is this correct?

Any help or pointers will be greatly appreciated. Thank you!

Daniel

+4  A: 

http://mercurial.selenic.com/wiki/TransplantExtension

See under "Using transplant to cherrypick a set of changesets".

Ideally you would do this with branches though?

ikanobori
Branches: Hmmmm, not really sure. I haven't had great success understanding Mercurial Branches :-) These are 2 different sites, which in my HD I have in 2 different folders... I know how to do that with branches in Vault, but how do I do it in Hg? When I tried to do some branching, I basically had ONE working folder, and I could change (*update*) which of the branches was showing there...
Daniel Magliola
I was suggesting having two branches in each of those folders (three total). One with the shared commits and one with the commits which will never go into the other repo. You merge in the shared branch with the specific branches when you need it :-) For an explanation on Mercurial branches: http://mercurial.selenic.com/wiki/Branch#Creating_a_Branch if you have more questions, do ask :-)
ikanobori
Ah, interesting. I'll experiment with that. Thank you for the idea!
Daniel Magliola
Also see Steve Losh's excellent Hg branching explanation at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Yawar
Having separate branches for your graphics changes and your shared commits means that neither set of changesets has the other as an ancestor, and so allows them to be pushed/pulled independently of one another.
shambulator
+3  A: 

I think of the commands this way:

  • hg bundle gives you a binary version of a changeset and hg unbundle will turn the bundle into exactly the same changeset on the receiving side.

    Bundle and unbundle are there to transfer changesets over, say, email and the binary patch depend on the parent changesets to be present..

  • hg export gives you a text representation of a changeset, and unless you use the --exact command line flag to hg import, then applying this patch wont create the exact same changeset on the receiving side.

    The advantage of not using --exact is precisely that you can apply such a patch anywhere as long as there are no textual conflicts.

  • hg transplant is just a thin wrapper around hg export and hg import.

Martin Geisler
I see. Thank you for the explanation, that makes sense, and it's really useful. Thanks!
Daniel Magliola