Assertion failure in _process_entry

[John Arbash Meinel]

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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
...

> 
> Well, I'd have thought it would make more sense to not have a record at all.

Well the memory storage is a grid, so you have to put *something* in
every hole. Having None would be equivalent to having 'a', except then
you would have to have lots of if/then conditions because rather than
always being a tuple of length 5, sometimes it might be None.

> 
>>> I wonder if you have pending merges, which are causing the record to
>>> have to be duplicated.
> 
> Yes, I do have pending merges.  From the steps-to-reproduce:
> 
> ~/sandbox$ bzr merge ../sandbox2
> +N  foo.OTHER
> Contents conflict in foo
> 1 conflicts encountered.
> ~/sandbox$ bzr status
> bzr: ERROR: exceptions.AssertionError: don't know how to compare
> source_minikind='a', target_minikind='r'
> 
> Aaron

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.

Actually, I had my values mixed up. 'target' is the working tree. And
source is one of the parents.

- 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? Or
maybe that is just how you've always handled the 'tree 1 deleted a file
that tree 2 modfied'.

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.)

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

iD8DBQFF8ZqcJdeBCYSNAAMRAv2WAJ4/FWgQMleUICu1jSErg1yN0Fn+XACfX5/M
yt7aEM5MVlu01PLNUTihWnY=
=L3si
-----END PGP SIGNATURE-----