Re: [Monotone-devel] merge conflicts

[hendrik]

On Wed, Dec 16, 2009 at 04:34:18PM -0800, Zack Weinberg wrote:
> 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.

Just a guess, but suppose one of the other repositories had previously 
done a merge resulting in a file that's different from the one the one 
user pushed.  It's possible that that merge result might conflict?  And 
I can't say I'd consider that a bug.

-- hendrik