@wgrant do you mean doing "bzr branch -r X lp:a-branch" where X is greater than the tip revision of a-branch?
I agree that we can trigger this, but it still seems a bit strange. "Branch.get_rev_id()" seems to be pretty rare. I would certainly argue that we should avoid it as much as possible.
Is it possible to figure out what is actually triggering this and fix it?
I think it is reasonable to change the api to not raise an AssertionError in this case (it makes sense at the Repository level, but at the Branch level it hides the 'known_pair' from the user.)
I'm not really worried about someone doing "bzr branch -r 10001" when there are only 10000 revisions. Unless this is something like a cron script that is trying to poll for 'newer' revisions by manually setting the target revision to something 'newer'.
We could possibly just return the 'history-incomplete' value, since from what I can see, the bzr client only trusts the response if it gets 'ok'.
@wgrant do you mean doing "bzr branch -r X lp:a-branch" where X is greater than the tip revision of a-branch?
I agree that we can trigger this, but it still seems a bit strange. "Branch. get_rev_ id()" seems to be pretty rare. I would certainly argue that we should avoid it as much as possible.
Is it possible to figure out what is actually triggering this and fix it?
I think it is reasonable to change the api to not raise an AssertionError in this case (it makes sense at the Repository level, but at the Branch level it hides the 'known_pair' from the user.)
I'm not really worried about someone doing "bzr branch -r 10001" when there are only 10000 revisions. Unless this is something like a cron script that is trying to poll for 'newer' revisions by manually setting the target revision to something 'newer'.
We could possibly just return the 'history- incomplete' value, since from what I can see, the bzr client only trusts the response if it gets 'ok'.