Bidirectional syncing on parallel branches

[John Szakmeister]

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