[MERGE] Let find_previous_heads take a repository.

[Aaron Bentley]

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

Johan Rydberg wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>>I'm not sure why that's such a bad thing.  If you're committing a
>>revision, it probably makes sense to use CommitBuilder.  If you're
>>adding texts for another reason, (importing, upgrading, installing a
>>bundle, data-recovery), it may not.
> 
> 
> Because some formats may not group changes on per-file basis.

Sure, and I agree those formats aren't suitable for writing to this way.
 But our core formats are suited to this, and I think that's a valuable
property.

> Think
> Subversions fsfs format.  For such history formats, implementing phony
> stores and VersionedFile-implementations is just an obstacle.

Annotate in particular is very slow on Subversion.  I think that's a
shame, but I'm not willing to demote annotate to an optional feature--
it's essential for knit merge.

Not only that, but formats vary all over the place.  RCS/CVS can easily
support annotate.  Annotation in Arch is also nice and fast.  Hg
apparently does a good job, too.

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

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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFElxob0F+nu1YWqI0RArrWAJ0aI0bjymmf9bHiwR9OEfXg0FotbgCePrwf
O6HqluOGlt4+v4S2ZqYuiw0=
=JWaW
-----END PGP SIGNATURE-----