Bidirectional syncing on parallel branches

[John Arbash Meinel]

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

John Szakmeister wrote:
> On Wed, Apr 21, 2010 at 10:50 AM, Stefan Monnier
> <monnier at iro.umontreal.ca> wrote:
>> How do people handle bidirectional syncing between two branches that are
>> meant to be different (ie. when properly sync'd there are still
>> differences between the two trees)?
>>
>> The way I imagine it working would be something like a new command:
>>
>>   bzr set-artificial-common-ancestor <otherbranch>
>>
>> which would not change anything to the content of the tip of the current
>> branch not of the otherbranch, but it would add to the history some info
>> saying that those two tips should be considered as "a common ancestor"
>> in future merges.
>>
>> So when a merge takes place later on, it will use this
>> artificial-common-ancestor to compute the diff to apply (that'd be
>> a diff4 style merge, I guess, but I could live with a simpler
>> diff+patch) and will mark the resulting revision as a new
>> artificial-common-ancestor.
>>
>> So if one later on wants to install a change on a branch that should be
>> visible to the other branch, one can simply commit the change and then say
>>
>>   bzr set-artificial-common-ancestor <otherbranch>
>>
>> again.  Not sure how easy/convenient it would be to implement and even
>> less sure what the semantics of such an artificial-common-ancestor would
>> be when other branches come into play.
> 
> I'd be really interested in the answer to this as well.  I think the
> current practice is to use looms or pipelines.  But I think they're
> both cumbersome.  That could be the lack of documentation/good
> tutorial on how to use them though.
> 
> -John
> 
> 

bzr merge ../other
bzr revert .  # '.' says revert only content, not merge point
bzr commit -m "Artificial common ancestor"

However, that only sets a common ancestor for one direction. Merging
back the other way will still try to pull in all the changes.

Alas, we don't have a good answer here, and DAGs don't lend themselves
to one.

Note that you *can* always do cherrypicks:

  bzr merge ../other -c -1

To just grab the latest changes in the other branch, etc.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvPHa8ACgkQJdeBCYSNAAN7pwCgo4zMejBjXdl2vI7yxqPrVpUx
NBUAoIJXHbdsXTCbOnUXBSreZS6r97u9
=juXe
-----END PGP SIGNATURE-----