[MERGE] Refactor fetch: add get_data_about_revision_ids to repository, and other changes.

John Arbash Meinel john at arbash-meinel.com
Fri Aug 3 13:40:14 BST 2007

Hash: SHA1

Andrew Bennetts wrote:
> This bundle is split out from my repo-refactor branch, which is working towards
> smart server support for streaming sets of revisions in a single request, rather
> than the easily thousands of requests that can occur right now.
> This particular bundle rearranges fetch.py a little.  Most interestingly, it
> moves some of the logic out of fetch.py, and moves it to a new method on
> Repository, get_data_about_revision_ids(revision_ids).
> I've gone through some small contortions to keep the progress bar handling the
> same as it was before.  I'm pretty sure this will need to change eventually, it
> doesn't feel right as it is, as the comments in the code now say.  I'd love to
> hear other people's opinions on what to do about this.  Similarly, the
> inventory_weave caching that was done in fetch.py is now a bit strangely done by
> get_data_about_revision_ids.  Probably this part should be moved back into
> fetch.py.
> -Andrew.


There was one thing that wasn't clear to me. Did you change the code so that
only new revisions have their signatures copied?

How do you propagate signatures that you put on older revisions? The current
code just does a full knit join (I believe) for all keys.

_same_repo() really seems like it should be a Repository member. Especially
since not all repos will have a 'control_files._transport' member.

It actually seems like a "__eq__" would be a reasonable way to do it.

For Robert's comments, what about "get_data_to_fetch_for_revision_ids"

Eventually you have to write sentences, and our functions are already getting
pretty long. Maybe:



Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list