[merge][#261315][1.7] RemoteBranch sets up stacking (more) correctly
Martin Pool
mbp at canonical.com
Thu Sep 18 00:45:06 BST 2008
On Thu, Sep 18, 2008 at 8:17 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> Well, you could use an "else:" clause in case there is no error. Though both
> exception handlers are just translating and raising an exception, so it is
> still 'safe'.
>
> Anyway, the reason to pull it out of the "try" code is because an exception
> there will also get caught, and it looks odd to raise an exception (even one
> that isn't caught) inside other exception handlers.
Fair point.
>> And if it's specifically called on the branch then we have to ask for it again.
>>
>> Arguably it should be cached inside the lock context. In practice
>> this may not be a priority because it's should not often be called
>> after opening the branch. So to really get a benefit here we'd want
>> to open the object locked, which would be useful in other cases, but
>> requires changing the opening api.
>
> It depends how often this needs to be called. If it is only during Branch.open
> so we can poke things into the Repository, it isn't a big deal.
It is.
> Also, was there a test that you can open a RemoteBranch and see it is stacked,
> and that if you do "rb._ensure_real()" that the rb._real_branch is also
> properly stacked?
Yes, there is, in test_get_stacked_on_real_branch.
> What about if you do "rb.repository._ensure_real()" (so you aren't going
> through the branch object anymore)?
This is not explicitly tested but it is covered: many of the methods
in RemoteRepository will do self._ensure_real and we observe that they
work properly. However, I should still set up a scenario to cover
more of the different operations you might do on a stacked remote
repository.
--
Martin <http://launchpad.net/~mbp/>
More information about the bazaar
mailing list