Failure to merge from BB

Tue Aug 12 21:18:48 BST 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One of the nice features that Aaron brought about with bundle buggy, is
the ability to merge patches directly via URL.

I don't know if anyone other than the two of us use it, but it recently
broke.

Specifically, trying to do:

bzr merge \
http://bundlebuggy.aaronbentley.com/download_patch/%3C019401c8fc2c$2118e7a0$634ab6e0$@com.au%3E

I get a traceback, ending with:
    new_bytes = self.read_bytes(1)
  File "C:\Users\jameinel\dev\bzr\bzr.dev\bzrlib\smart\medium.py", line
121, in read_bytes
    return self._read_bytes(bytes_to_read)
  File "C:\Users\jameinel\dev\bzr\bzr.dev\bzrlib\smart\medium.py", line
124, in _read_bytes
    raise NotImplementedError(self._read_bytes)
NotImplementedError: <bound method HttpTransport_urllib._read_bytes of
<bzrlib.transport.http._urllib.HttpTransport_urllib
url=http://bundlebuggy.aaronbentley.com/download_patch/%3C019401c8fc2c118e7a0
34ab6e0com.au%3E/>>

Now, as near as I can tell, it is trying to probe for the Smart Server
and failing on "_read_bytes" not being implemented.

If I revert back to -r 3500, I get:
bzr: ERROR: Unknown bzrdir format: '<!DOCTYPE HTML PUBLIC "-//W3C//DTD
HTML 4.01 Transitional//EN"

Which includes some sort of 404 in there.

Same thing for pre 3400 and beyond.

I get the feeling that the 404 for .bzr/branch/format is not happening
properly.

And I see the same thing if I go to the page:
http://bundlebuggy.aaronbentley.com/download_patch/%3C019401c8fc2c$2118e7a0$634ab6e0$@com.au%3E/.bzr/branch/format

It *says* 404, but I'm not convinced the actual 404 header is given.

Trying to debug with -Dhttp and -Dhpss is mostly confusing me.

Specifically, it seems like it should be downloading the patch and working:

0.577  > GET /download_patch/%3C019401c8fc2c118e7a034ab6e0com.au%3E
0.577  > Host: bundlebuggy.aaronbentley.com
> Accept: */*
> User-Agent: bzr/1.7dev (urllib)
> Connection: Keep-Alive
> Pragma: no-cache
> Cache-Control: max-age=0

0.702  < HTTP/1.1 200 OK
0.702  < Date: Tue, 12 Aug 2008 20:13:50 GMT
< Server: CherryPy/2.3.0
< Content-Length: 696

^- isn't that downloading the Merge Directive? (Though 696 bytes seems
incorrect.)

Then bzr checks to see if there is a smart server anyway:

0.748  hpss call:   'hello',
0.748               (to
http://bundlebuggy.aaronbentley.com/download_patch/%3C019401c8fc2c118e7a034ab6e0com.au%3E/)
0.748  > POST
/download_patch/%3C019401c8fc2c118e7a034ab6e0com.au%3E/.bzr/smart
0.748  > Content-Length: 6
> Connection: Keep-Alive
> Accept: */*
> User-Agent: bzr/1.7dev (urllib)
> Host: bundlebuggy.aaronbentley.com
> Pragma: no-cache
> Cache-Control: max-age=0
> Content-Type: application/x-www-form-urlencoded

1.185  < HTTP/1.1 200 OK
1.185  < Date: Tue, 12 Aug 2008 20:13:50 GMT
< Server: CherryPy/2.3.0
< Content-Type: text/html; charset=utf-8
< Status: 404

And it gets a 200 OK, which sounds like cherrypy is happy to respond to
the POST.

Right after that, I get a traceback, because I think CherryPy is saying
"Thanks for the request, 200 OK that is a 404".

Is Status: 404 supposed to supersede the 200 OK response?

Anyway, at a minimum I think BB is giving confusing responses, though
probably 'bzr' might be misinterpreting them?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkih8CgACgkQJdeBCYSNAAPQTgCgsnv3tvJ6+buxy6mKD0qCxlEE
cOMAnRWq4snQwOWgss7spkIko1kISpgt
=KvoY
-----END PGP SIGNATURE-----