[MERGE] RevisionSpec.as_revision_id()
John Arbash Meinel
john at arbash-meinel.com
Thu Mar 20 22:56:41 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The attached patch does 2 things to improve our --revision specs.
1) We had a general meme of doing:
~ rev_id = revision[0].in_history(some_branch).rev_id
~ Lukas noticed this, and added a 'need_revno' flag which would allow the
~ RevSpec to skip computing revision numbers.
~ I went one step further and just switched to
~ rev_id = revision[0].as_revision_id(some_branch)
~ I think it is both clearer, *and* we should probably try to deprecate
~ .in_history() at some point. Our internals pretty much universally work in
~ terms of revision ids. And generally where they don't, they should be updated
~ so that they do.
~ The only place I know that we use revno here and there is in Log, and
~ Uncommit (because uncommit displays the log.)
2) Branch6.get_rev_id() is now lazy about looking up revision_history and
~ spitting out the revision_id for a given revno. Lukas did most of this work,
~ I just poked at it a bit. I was hesitant at first, but now I feel like I
~ understand what is going on, and I feel like it is reasonable.
~ The one thing I didn't do here was to change Repository.iter_reverse...
~ Because I approved Robert's patch which cleans it up, and I didn't want us to
~ conflict on how we ended up fixing it.
This should make *most* instances of 'bzr foo -r XXX' faster. Especially for
stuff like -r ancestor: where we would often spend a lot of time to compute the
revno and then throw it away afterwards.
I'll still be around tomorrow if people have suggestions to how to clean this
up, but after that, I'll be on vacation.
I really think something like this will help with projects like Emacs that have
very long mainline histories.
This should still be backwards compatible for people who implement their own
revision specs, as long as the inherit from RevisionSpec. I also planned ahead
for api compatibility and have classes override an intermediate function, rather
than the public function. (That way implementations can get some help for
compatibility.)
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH4uupJdeBCYSNAAMRAvJdAJ9/yfdwQKv6ixe9VdnxN4xQevTlkgCgx//V
r/5YYEfBMdWBty0bz+AHHds=
=X6pb
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: get_rev_id.patch
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20080320/e3c7b568/attachment-0001.diff
More information about the bazaar
mailing list