Assertion failure in _process_entry

Aaron Bentley at
Fri Mar 9 17:51:17 GMT 2007

Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:

>> bzr: ERROR: exceptions.AssertionError: don't know how to compare
>> source_minikind='a', target_minikind='r'

> There is certainly a case that needs to be handled. I'll try to get to
> it today. My best guess is that source = 'a' and target = 'r' is
> something that can just be skipped. Since we should hit it at a
> different time.

Well, *somewhere*, it should be treated as creation + versioning of the

> - From you steps to reproduce, though. It seems weird that we are getting
> a 'r' record (renamed). But I guess you are versioning 'foo.OTHER'
> rather than 'foo'. Is it because foo is on disk but not versioned?

No.  foo is not on disk.

> Or
> maybe that is just how you've always handled the 'tree 1 deleted a file
> that tree 2 modfied'.

It's the general-case handling of content conflicts (rather than text
conflicts).  If all three trees disagree on the contents, and the file
is not a regular file in THIS or OTHER, it will produce foo.THIS,
foo.BASE and foo.OTHER. (and there will be no foo)

If the file is deleted in THIS or OTHER, the corresponding copy of the
file is not emitted.

If possible, foo.THIS is versioned.  If it's not present, then foo.OTHER
is versioned.

> This certainly seems like a case to be added to
> intertree_implementations.test_compare.
> (Though it could also be just a specific case.)

I always have trouble deciding, but since there are known to be multiple
implementations of _iter_changes, I think it makes sense to test each one.

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the bazaar mailing list