[MERGE] compare_trees with all unknowns

[John Arbash Meinel]

Robert Collins wrote:
> On Thu, 2006-07-27 at 10:25 -0500, John Arbash Meinel wrote:
>> Robert Collins wrote:

...

>> Well, I think the 'three-way-split' is actually going the other way. (We
>> require file-like objects to be passed in, rather than strings or lists
>> of strings).
>> It really isn't relevant on the way out. If you got a file-like object,
>> you can just issue .read() or .readlines().
>>
>> You decided you didn't want magic interfaces, so all of our interfaces
>> now just require a file-like object.
>> It would be reasonable to change them to an iterator of strings, as
>> Aaron would like, since that works for files, strings, and lists of strings.
>>
>> But we have the performance issue of iterating over a plain string,
>> which would mean an 'if isinstance()' which you didn't want.
> 
> Isn't that addressed by having an explicit interface to get what you
> want?

The problem generally isn't in the 'get' side, it is in the 'put' side.
Our general problem is that we already have something as a string in
memory. One of the most common is that we have a test case where we set
the text to an explicit value, but another might be we had to read
something, verify it, and then put it back somewhere else.
grep'ing through the source, I mostly see us setting files with fixed
values (file headers, etc).
Grep for 'StringIO' and 'put_utf8'.

Anyway, we have a string, and we want to Transport.put() (or append) it.
So we have to turn it back into a file-like object with StringIO.

This is just in your mention that 'we need this because we have to use
StringIO'. And that isn't really true.

> 
>> So I think you are fixing the wrong direction by adding
>> 'get_file_text()'. But I'm not going to block on it.
> 
> Ah. So the thing is - we *already have it* on some Trees. I'd rather we
> use it consistently, or remove it. As its a read only interface, it
> seems reasonable to promote it to use from the base interface to me.
> 
> Rob

Sure. I'm fine with it existing. I would rather get away from
get_*_lines(), because I think we can be more efficient working with
large hunks of text, not necessarily split on line boundaries.

If we want 'get_file_text()' as part of the Tree interface, I'm okay
with that. I suppose there are some implementations where getting the
text can be more efficient than getting a file-like object.

So +1 all around I guess.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060727/e33138a5/attachment.pgp