[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