Thanks, this looks like a good change overall. Unfortunately, it's breaking a unit test (specifically,
rbtools.clients.tests:MercurialClientTests.testDiffBranchDiverge). You can run this with nosetests:
$ nosetests -v rbtools.clients.tests:MercurialClientTests.testDiffBranchDiverge
According to the test failure, resulting diff contains more changes than the unit test expects.
Based on the bug post you tweeted earlier today, I don't know if you're up for looking into this
further and making changes. If not, we'll work to get it in.
Calculate outgoing Mercurial changesets from current revision
Review Request #5066 — Created Dec. 7, 2013 and submitted
Previously, RBTools calculated outgoing Mercurial changesets by asking
Mercurial about *all* changesets on the current branch not in the
remote. While this works, it's not ideal. This querying is expensive
since it pulls in all changesets, not just ancestors of the eventual
With this patch, we now pass "-r ." into hg outgoing. This limits the
lookup to changesets that are ancestors of the working copy. In some
repository configurations (such as my own, where I have bookmarks
tracking thousands of changesets that will never be pushed to the
remote), this drastically speeds up diff computation and makes RBTools
I updated the patch to make tests work again. Essentially, I retained the behavior of only consulting the current branch instead of all branches. I should have done this from the beginning.
I rebased my changes on top of since-landed refactors.
I added a bunch of rev= arguments to the API. While the only consumer of these functions is currently the "get revisions for len(revspec) == 0" case, it may seem like I could have just hardcoded rev='.' in the final function. However, having flexibility is nice. Besides, I /think/ computation of parent diffs (a feature I'd like to implement) will rely on this argument. If you strip things before commit, I won't feel bad.
Revision 2 (+22 -10)
Looks great. Thanks!