Assertion failure in _process_entry

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
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
file.

> - 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 test_workingtree_4.py 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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF8Z6V0F+nu1YWqI0RAufIAJ9on8WEtZZZY/Z7O6UDF9XSaBcwhwCfbD53
zxFUDvONe+8R66EqB2vGQGI=
=jijW
-----END PGP SIGNATURE-----