[MERGE] Let find_previous_heads take a repository.

[Johan Rydberg]

John Arbash Meinel <john at arbash-meinel.com> writes:

>> VersionedFile extends RepositoryFile, so there is no need to alter the
>> existing VersionedFile implementations (knits and weaves).  
>> 
>> We need a per-file interface for retrieving history information out of
>> the repository.  This is what RepositoryFile is meant for.
>
> Why can't you just use VersionedFile with some methods NotImplemented?

Personally I would not reject the idea of having a get_versioned_file
method in Repository, _as long as_ the user of it is well aware that
it may not implement the whole VersionedFile API.  I'm afraid some may
be tempted to use it instead of for example CommitBuilder to add new
texts to a file.

> Between being more obvious, and maybe performing better, I would prefer
> Aaron's method.

OK.

> Why do you prefer returning a stripped down object, rather than having
> the call directly on Repository. Your RepositoryFile interface takes no
> constructor, and saves no state. So it is obviously never returned. I
> suppose it defines a potential API. But as it stands the class
> definition is next to useless.

Because it limits what can be done on a repository file.  And I think
it is a better API than having N get_file_* methods in Repository.

Yes, the RepositoryFile implementation used by knits and weaves are
state-less and simple, but that may not be the case for every format.

~j