Comment 7 for bug 409615

Martin Pool wrote:
> 2009/12/1 David Muir <email address hidden>:
>
>> I'm a little confused by terminology... and Python in general...
>> IIUC, the transport assumes append based file streams (because of previous
>> limitations?). So even though the method is called append_file, having it
>> put the file instead is ok?
>>
>
> What's supposed to be happening here is that we are streaming out from
> the groupcompress level, which is going to write one long file in a
> series of chunks. The base class implementation in transport.py and
> AppendBasedFileStream changes them into a sequence of
> transport.append_bytes calls. However, since some servers don't
> support append, we need to make sure that by the time it gets to the
> ftp level we just open the file once and write one long stream.
>
> By the way for openftpd I think there is a configuration option to
> allow appending. But patches to avoid needing to set it would still
> be great.
>
>
Ok, I was able to get it working by skipping the if self._has_append
part, and just using self._fallback_append()
Probably not the ideal solution, but it worked :-)

Let me know if I'm on the right track and how it can be improved.

=== modified file 'bzrlib/transport/ftp/__init__.py'
--- bzrlib/transport/ftp/__init__.py 2009-10-06 08:24:14 +0000
+++ bzrlib/transport/ftp/__init__.py 2009-12-02 01:48:45 +0000
@@ -397,12 +397,12 @@
             result = ftp.size(abspath)
         else:
             result = 0
-
- if self._has_append:
- mutter("FTP appe to %s", abspath)
- self._try_append(relpath, text, mode)
- else:
- self._fallback_append(relpath, text, mode)
+ #is this if/else required anymore?
+ #if self._has_append:
+ # mutter("FTP appe to %s", abspath)
+ # self._try_append(relpath, text, mode)
+ #else:
+ self._fallback_append(relpath, text, mode)

         return result