Re: [Monotone-devel] merge conflicts

[Zack Weinberg]

On Wed, Dec 16, 2009 at 1:43 PM, Hugo Cornelis <address@hidden> wrote:
> This behavior makes it hard if not impossible to fully automate
> regression testing for a software product.
>
> From viewpoint of the concepts, I would think that a merge conflict
> resolution implemented by one user and pushed to a central repository,
> would be honored automatically by repositories that only pull from
> that central repository, such that these 'pull-only repositories' can
> continue to serve their task.  But our experience indicates otherwise:
> after manual resolution of all merge conflicts in one repository that
> occasionally syncs with the central server, we still have to go
> through other repositories that only pull from the server to resolve
> what is essentially the same conflict.  This behavior just seems
> incorrect.

Me and njs spent quite some time with a whiteboard back in the day,
trying to convince ourselves that the least common ancestor selection
algorithm would not do this.  I think you have found a bug.  Thing is,
though, it's gonna be something obscure and specific to your use
pattern, because all the simple scenarios are already in the test
suite.

Can you please try to write a shell script that demonstrates the
effect by a sequence of commit, merge, and sync operations on
synthetic databases?  That will make it much easier to figure out
what's going on.  I could try to write one based on your description
of the problem, but I estimate at least 75% chance I won't be able to
make it happen.

zw