[MERGE] Teach 'bzr remerge' to not use 'iter_conflicts'

John Arbash Meinel john at arbash-meinel.com
Tue Oct 17 01:52:55 BST 2006


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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> The attached patch changes 'bzr remerge' to not use
>>> 'WorkingTree.iter_conflicts()'.
>>>
>>> iter_conflicts() is actually a slightly broken way of finding conflicts
>>> because it only looks at file suffixes (which means a file called
>>> foo.BASE will always be marked as conflicted).
> 
> The other thing about iter_conflicts is that it reports only contents
> conflicts, not other types.
> 
>>> Which is why it was deprecated
> 
> I never supported that deprecation.
> 
>>> in favor of using
>>> WorkingTree.conflicts(). Which for new versions just consults the
>>> conflict file.
> 
>>> remerge required iter_conflicts() because it reset the conflict file
>>> before going on to the next step, which needed to know what files were
>>> actually conflicted.
> 
> Remerge only needs to know about contents conflicts, and it will
> misbehave if it encounters other conflict types.

We can filter based on whether it is a content conflict, but using
'iter_conflicts' will also cause us to flag real versioned files that
happen to end with .BASE, .THIS, or .OTHER. Which is also a bug, though
perhaps less obvious.

What about this one:

# Remerge only supports resolving contents conflicts
allowed_conflicts = ('text conflict', 'contents conflict')
restore_files = [c.path for c in conflicts
                 if c.typestring in allowed_conflicts]

This passes the test suite, and should satisfy your 'only allow text or
content conflicts'.

You claimed remerge only supports 'content conflict', but when I did not
include 'text conflict' the test suite didn't pass. And I saw that old
working tree formats used to return both of these types.

Further, it seems that our testing of 'remerge' is incomplete, if it
would bork when supplied other types of conflicts, but my changes do not
filter them as expected. (For example, we should have a remerge test
that has multiple types of conflicts in the tree, and makes sure remerge
doesn't die when they are present).

I think _iter_conflicts is broken because it assumes file endings have
meaning, which is only approximately true. I think we switched to
'WorkingTree.conflicts()' for that express purpose. And if there are
limitations of remerge, that is fine, but we should hand it the right
stuff, rather than failing when someone starts versioning files with a
specific extension.

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

iD8DBQFFNClmJdeBCYSNAAMRAqB0AKCDyNGpO9PjREqYgSvSv+eY7gZWPgCfcvdO
dY7tVX2m5xNmvlIKa+bYu7s=
=0dbB
-----END PGP SIGNATURE-----




More information about the bazaar mailing list