[MERGE][1.6] lookup rules using get_special_file API

[Ian Clatworthy]

John Arbash Meinel wrote:

> So a few comments:
> 
> 1) In test_tree_implementations you add the file with the id "xyz-id" so
> it isn't 100% clear that it isn't mapping via adding "-id". It is a
> small thing, but it might be clearer that the file-id is actually a
> random one.

Sure.

> 2) I'm a bit concerned that the base 'Tree' implementation requires the
> file to be versioned, but the one in WorkingTree does not.
> 
> For something like 'get_special_file' it feels like you should be doing
> a lookup check, to make sure that .bzrrules is versioned, even if it
> isn't committed yet.
> 
> Or did you explicitly want to support unversioned special files?

I don't care either way at this point. I'll look at what we do for
.bzrignore and make it consistent.
> 
> 3) So I would like to see a workingtree_implementations test that
> defines the behavior of non-versioned special files. I'll leave it to
> you to decide whether they get returned or not.

OK.

> 4) Oh, and I'd rather get_special... returned either Lines, Chunks, or
> Text. Mostly because then we don't have to worry about the caller
> explicitly calling '.close()' on the returned object. I don't think most
> callers are going to think about it, and not try/finally:foo.close()ing
> your files causes problems on windows.
> 
> (I would really like to be switching apis to be 'chunks' as "lines" and
> [fulltext] are both proper chunks and eliminate the need to be casting
> between types all the time, but for this api, plain "get_file_bytes"
> "get_file_text" or "get_file_lines()" are fine.)
> 
> I believe on Tree we would do either _text or _lines.

Hmm. I'm not fond of "lines" because that implies that special files are
always "text" when some might be binary one day. Let me think about
this suggestion a bit more. I agree with your concern btw.

Ian C.