Bidirectional syncing on parallel branches

[Jelmer Vernooij]

On Wed, 2010-04-21 at 10:50 -0400, Stefan Monnier 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.
There isn't a really good answer to this at the moment.

rebase contains some initial work to rewrite one of the two branches
using the revision ids and file ids of the other, but that's of course
not an ideal solution. 

I've brought up this issue on the ubuntu-distributed-devel mailing list
earlier:

https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-February/000532.html

Cheers,

Jelmer