Transplant workflow question

[Martin Geisler]

Hugues Lismonde <hugues.lismonde at gmail.com> writes:

> Work is done on both the "main" project and the clones and I cherry
> pick the changes I want from the clones back into the main project
> (since some of the changes are specific to the client, this works very
> well).
>
> Then, when I make some correction in the base project and I pull them
> into the clones. This also work well but the transplanted changesets
> are pulled alongside the new as another branch and merged. Until now
> it works but I feel it may not be as clean as it should.

I agree that it looks a bit iffy, but it's a natural consequence of you
creating two changesets with the same change and commit message but
different ancestors. Because of the diffent ancestors, the two
changesets are given differnet hashes, and thus different identities.
But the behavior you see is entirely normal.

> I'd rather not transplant back and forth changes but if it's the
> safest way I'll follow it.
>
> Is there another way to maintain client branches without pulling in
> the base repository changes/modules specific to those clients? While
> keeping the possibility to update them simply by push/pull between
> repositories?

You could use the histedit and rebase extensions to keep the
customizations as a linear sequence of changesets on top of the main
repository. If you discover that a customization belong in the main
repository, then you use histedit to move it back in history to the tip
of the main repository after which you can pull it into main.

So if main has a and b and you create x, y, z:

  ... [a] --- [b] --- [x] --- [y] --- [z]

then after a pull from main you might end up in this situation:

  ... [a] --- [b] --- [x] --- [y] --- [z]
                 \
                  [c]

Instead of merging c and z, you rebase x-z on top of c (that is just a
simple call to 'hg rebase' after pulling):

  ... [a] --- [b] --- [c] --- [x'] --- [y'] --- [z']

The old x-z changesets are now replaced with changesets x'-z' which
contain the same patches, but have different changeset hashes (because
of their different ancestors).

If you decide that z' is a super cool change that you want in the main
repository, then histedit will let you move it in-between c and x':

  ... [a] --- [b] --- [c] --- [z''] --- [x''] --- [y'']

The changesets get a hash again becuase you've edited their ancestors.

I don't know how practical this really is -- I've never tried a workflow
like this. The mq extension lets you do the same, but where you keep the
customizations as patches. I believe using rebase and histedit gives you
better merges and more robust failure handling since they work on
changesets instead of patches.

Finally, the attic and shelve extensions might let you stow away your
customizations in an easier way, but I have no experience with them.

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20090905/8582419b/attachment.pgp