hg transplant, rebasing, and merging

[Benjamin Smedberg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gábor Farkas wrote:

| hmmm.. could you create a test-case for this?
| a shell script that creates a repository where this problem is visible?

Attached.


|> * However, there are some minor (or major) conflicts... so simply taking
|> patches and applying them to the new tip doesn't work very well.
|
| as far as i know, when you do the 'transplant' step, it will start
| transplanting the changesets, and if there is a conflict, it simply
| stops and you have to fix the conflict, and then do something like 'hg
| transplant --continue'. is this behavior not suitable?

The question is, how do you fix the conflict? Is the conflict presented as a
.rej file from patch, or is it presented in a three-way merge tool? AFAICT
transplant only tries to apply a patch, instead of doing three-way merge.

| but, as far as i understand, Bob simply made a mistake. if he creates 3
| unrelated local commites, he should simply do them in 3 branches. after
| all, the commits are unrelated, so they should not be in the same branch
| while they are developed.imho. of course, maybe i'm misunderstanding
| something here, please tell me if that's the case.

As dbaron noted a while back, on a project of Mozilla's scale, creating a
separate local repository for each possible task is not practical. Simply
compiling each branch can require an hour or more. It is far easier to do
the three commits in a single local tree that is already built and rearrange
them prior to push.

- --BDS

- --

Benjamin Smedberg
Platform Guru
Mozilla Corporation
benjamin at smedbergs.us
http://benjamin.smedbergs.us/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHwvCnSSwGp5sTYNkRAjXYAJ9kwS6+LFfnWP/mAeEqCifr6dd9dgCguHIt
43bAaaUropJcue+7c3Vs24E=
=OTVx
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rebase-merging.sh
Url: http://selenic.com/pipermail/mercurial/attachments/20080225/c997e24a/attachment.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rebase-merging.sh.sig
Type: application/octet-stream
Size: 65 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20080225/c997e24a/attachment.obj