Transplant workflow question

[Hugues Lismonde]

On 05 Sep 2009, at 14:42, Martin Geisler wrote:

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

Make sense. I somewhat hoped the changeset would keep the same data  
when transplanted into the main repos (deep down I knew it wasn't the  
case)

>
>> 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]
>
It maybe more like:

[a] --- [b] --- [x-t] --- [y-t] --- [z-t] --- [c] in main repos

[a] --- [b] --- [x] --- [y] --- [z] -------------------[m] in client  
repos
                  \ -[x-p] --- [y-p] --- [z-p] --- [c] -/
-t: transplanted
-p: pulled

> 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']

If I somehow rebase everthing "as it should" I assume transplant will  
ask me again for the "new" x,y and z so it may be even worse.

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

I fell this rebase/histedit workflow is a bit complex just to have a  
"clean" history. If I don't run into merge troubles I'll keep it that  
way for now, as the project matures, this kind of back and forth  
should be less frequent as most of the work will be done in main.

> Finally, the attic and shelve extensions might let you stow away your
> customizations in an easier way, but I have no experience with them.
I'll look into that and see if it could fit the purpose.

Thanks for your help, it's a bit more clear for me.

Hugues

>
> -- 
> Martin Geisler
>
> VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
> SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial