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

Bug #230550 reported by Andrew Bennetts on 2008-05-14
Affects Status Importance Assigned to Milestone
Andrew Bennetts

Bug Description

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: '', '.'
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: '', '.'
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: '', '.'
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.

Related branches

Andrew Bennetts (spiv) wrote :
Robert Collins (lifeless) wrote :

This is a blocker for users

Changed in bzr:
importance: Undecided → Critical
status: New → Confirmed

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) wrote :

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.

Changed in bzr:
assignee: nobody → spiv
status: Confirmed → In Progress
Andrew Bennetts (spiv) wrote :

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

Changed in bzr:
status: In Progress → Fix Committed
Andrew Bennetts (spiv) wrote :

Fixed in The fix will be in bzr 1.6.

Changed in bzr:
milestone: none → 1.6
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments