bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2

[Andrew Bennetts]

This was originally reported on IRC by brilliantnut.

A "bzr log bzr+http://..." command results in this error:

    NoRepositoryPresent: No repository present: "bzr+http://<email address hidden>/bzar/HEAD/"

However there is a repository present at the "bzar" directory.

Here's the transcript of the smart protocol conversation from the .bzr.log:

0.218 bzr arguments: [u'log', u'-Dhpss', u'-Dhttp', u'bzr+http://ujjwal.kabra:f
<email address hidden>/bzar/HEAD']
0.437 hpss: Built a new medium: HttpTransport_urllib
0.437 hpss call: 'hello',
0.437 (to http://<email address hidden>/bzar/HEAD/)
1.156 result: 0.719s 'ok', '2'
1.187 hpss call: 'BzrDir.open', '.'
1.187 (to http://<email address hidden>/bzar/HEAD/)
1.484 result: 0.297s 'yes',
1.484 hpss call: 'BzrDir.open_branch', '.'
1.484 (to http://<email address hidden>/bzar/HEAD/)
1.828 result: 0.344s 'ok', ''
1.828 hpss call: 'BzrDir.find_repositoryV2', '.'
1.828 (to http://<email address hidden>/bzar/HEAD/)
2.234 result: 0.406s 'ok', '..', 'no', 'no', 'no'
2.234 hpss call: 'BzrDir.open', '.'
2.234 (to http://<email address hidden>/bzar/HEAD/)
2.593 result: 0.359s 'yes',
2.593 hpss call: 'BzrDir.find_repositoryV2', '.'
2.593 (to http://<email address hidden>/bzar/HEAD/)
2.937 result: 0.344s 'ok', '..', 'no', 'no', 'no'
2.937 hpss call: 'BzrDir.open', '.'
2.937 (to http://<email address hidden>/bzar/HEAD/)
3.250 result: 0.313s 'yes',
3.250 hpss call: 'BzrDir.find_repositoryV2', '.'
3.250 (to http://<email address hidden>/bzar/HEAD/)
3.562 result: 0.312s 'ok', '..', 'no', 'no', 'no'

It appears that the ".." from find_repositoryV2 being ignored (perhaps the transport.clone('..') is having no effect?), so the client keeps probing the same (wrong) directory for the repository.

I'll attach the full .bzr.log that was pastebinned on IRC.

[Robert Collins (lifeless)]

This is a blocker for users

[Ricardo Kirkner (ricardokirkner)]

I tried this with bzr 1.4 and it presented the same issue. However, I tried it with bzr 1.3.1 and it worked ok. I later tried it with bzr 1.5 and it produced the same result (error). All three tests were done using bzr 1.4 (and later bzr 1.5) on the server side.

This might be a bug introduced by bzr 1.4.

So for now, this can be solved by using bzr 1.3.1 on the client side.

[Andrew Bennetts (spiv)]

This is due to a bug in the logic for reusing _SmartClient objects and SmartClientMedium objects. The base path of the two can get out of sync, so code that thinks it is generating a request for a particular path is actually requesting different path.

I've got a possible fix locally, by cleaning things up so that SmartClientMedia track their base themselves, rather than relying on other code to track it in perfect synchrony. This is probably the right thing to do anyway.

[Andrew Bennetts (spiv)]

I've sent a fix for this to the list for review.

[Andrew Bennetts (spiv)]

Fixed in bzr.dev. The fix will be in bzr 1.6.