problems with bzr 0.10 and paramiko sftp transfer

[Robey Pointer]

On 29 Aug 2006, at 12:17, John Arbash Meinel wrote:

> 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.

For what it's worth, I had a weird '\n' error pop up when I tried to  
update my pushed "no_has_key" branch earlier today, too.  I ended up  
erasing the tree and doing a clean push to work around it.

I'm not using any special apache config, nor have I updated it in the  
past few weeks (probably even few months), so I think we can rule out  
apache... or at least, any *new* apache behavior.

robey