[MERGE] Let find_previous_heads take a repository.

[Johan Rydberg]

Aaron Bentley <aaron.bentley at utoronto.ca> writes:

>> jelmer's subversion plugin has just this; FakeFileWeave, FakeFileStore
>> and FakeInventoryWeave.  If the interface requires you to do this, I
>> think the interface is flawed.
>
> I disagree with you here.  I think the reason jelmer's plugin has these
> is because it's a worse format, and adapting ourselves to it would be a
> a lowest-comon denominator approach.  I prefer to keep support for our
> own formats as primary.  That means other formats will need need
> additional support data like annotate snapshots or file-id <->
> revision/path mappings, or other kinds of caching.

I agree with you that we must have code that support our primary
formats in an effective and natural fashion, but that doesn't mean we
can not have an interface that allow for other formats to plugin in a
somewhat simple manner.

For example, I've written a generic repository fetcher that uses the
CommitBuilder to transfer revisions.  It is far from optimal,
performance wise, but is needed to upgrade and fetch between two
totally different formats.  

_But_ it will not effect the primary formats, which still uses
GenericRepoFetcher (renamed to VersionedFileRepoFetcher) to do
non-compatible inter-repository operations.

> I really don't want bzr to get a new API layered on top of the old one
> unless it benefits the core of bzr.  More APIs, especially layered APIs,
> make code harder to understand.  If we have a RepositoryFile API, I will
> have to ask myself, for every operation, "Is this supported by the
> RepositoryFile API?  Should it be?"  API layering should be clear and
> intuitive, but I have no idea what operations should take place on
> RepositoryFiles, and what should take place on VersionedFiles.

OK.  I agree it might be better to keep VersionedFile as it is, and
scrap RepositoryFile.  I would still like to see a get_versioned_file
method in Repository.

> I welcome CommitBuilder, because I think it makes the commit code easier
> to work with.  But RepositoryFile doesn't seem to buy us much.  Since
> Blob-format doesn't seem to be coming soon, I would save this kind of
> change until blob format does come, and then shape it to whatever blobs
> need, not for the lowest common denominator.

That's more or less what I'm doing right now; working my way towards a
blob-like history format.  It's mostly research, but hopefully
something useful will come out of it.

Believe me, I'm not proposing these changes just to piss you off. :)

~j