[MERGE] Let find_previous_heads take a repository.
Aaron Bentley
aaron.bentley at utoronto.ca
Mon Jun 19 23:50:58 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johan Rydberg wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:
>
>
> 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.
Yes, and CommitBuilder is a pretty good example here. Using it for
committing to both bzr and svn is pretty optimal.
Doing things in a performant way does mean assuming some lower-level
details. For example, if we were converting RCS files into knits, we
could take advantage of their similar compression approaches to avoid
rediffing every version.
For example, the new get_revisions() call on VersionedFile wouldn't be
any advantage on a Subversion-backed Repository, but cuts down I/O
operations on VersionedFile respositories significantly.
> 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.
Yes, I agree. We have far too many 'get*weave*' calls in our code.
>> 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.
Well, it's an interesting idea. I guess my biggest concerns are local
and network performance, but if you can solve those, great.
> Believe me, I'm not proposing these changes just to piss you off. :)
No worries.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFElypS0F+nu1YWqI0RAlcrAJ43hmvravVwbf0jj6FpoVfWyZ/3HACeNBPE
yJyZvc4VeiyMjkUqQ7jlIs4=
=ZNyx
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list