problems with bzr 0.10 and paramiko sftp transfer

[John Arbash Meinel]

Lukáš Lalinský wrote:

...

> F:\tmp>bzr branch http://www.lag.net/paramiko/bzr/paramiko/
> bzr: ERROR: Knit header error: '\n' unexpected
> 
> But yes, with trunk it works fine.

I just looked at Robey's branches, and I'm getting the same error.

If I browse to his repository using Firefox, I think I see why we are
getting the error, but I don't know if it is because of a problem with
Apache, or if there is actually a problem with the branch.

If you go to:
http://www.lag.net/paramiko/bzr/paramiko/.bzr/repository/inventory.kndx
or
http://www.lag.net/paramiko/bzr/paramiko/.bzr/repository/revisions.kndx

Now there are a few things:

1) There is no 'Knit index format 8\n' header at the top of the file.
There should be something similar to this:
http://www.lag.net/paramiko/bzr/paramiko/.bzr/repository/signatures.kndx

Now, this header actually has an extra blank line between the header,
and the start of data.

So my feeling is that Apache is misconfigured, and it is sending this
line out as part of the Headers for the file, rather than as part of the
Body of the file. (since HTTP headers are separated by 2 CRLF pairs).

2) We probably have a bug in Knit.join() code.
            if version in self._cache:
                # -- inlined lookup() --
                result_list.append(str(self._cache[version][5]))
                # -- end lookup () --
            else:
                result_list.append('.' + encode_utf8(version))

Which seems to say that we only add a '.<revision_id>' if the version
does not exist in 'self._cache'. But if you look, you can see that we
have the parent in the file already. My guess is that the parent was
added during a join() operation, and the index._cache isn't being kept
up to date.

Actually, I think I can prove that. If you look at
_KnitIndex.add_versions()
It iterates over the versions to add, and uses
self._version_list_to_index() on each one.
But it doesn't call self._cache_version() until after it has iterated
over the list. With the statement:
    # cache after writing, so that a failed write leads to missing cache
    # entries not extra ones.

I do realize that there can be some race conditions for dictionary
compressing new entries. Because if someone else appends to the file
while you are appending to it, suddenly all of your dictionary lookups
are incorrect. Even though both appends are successful.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060829/e825048f/attachment.pgp