bzr-fastimport on Windows

Paul Moore p.f.moore at gmail.com
Tue Mar 11 21:04:10 GMT 2008


On 10/03/2008, James Westby <jw+debian at jameswestby.net> wrote:
> So, I did some digging and I found the code to dump a file is this:
>
>  def dump_file_blob(root, full_path, pool):
>     stream_length = svn_fs_file_length(root, full_path, pool)
>     stream = svn_fs_file_contents(root, full_path, pool)
>     sys.stdout.write("data %s\n" % stream_length)
>     sys.stdout.flush()
>     ostream = svn_stream_for_stdout(pool)
>     svn_stream_copy(stream, ostream, pool)
>     svn_stream_close(ostream)
>     sys.stdout.write("\n")
>
>  I'm not sure whether this is correct. The code needs to dump out
>  exactly the contents of the files, with the exact byte length.
>  I guess the line endings support in svn would interact with this,
>  though if svn_fs_file_length didn't equal the length of
>  svn_fs_file_contents I would call it broken.
>
>  Can you confirm if you have any line ending properties set on
>  any of the problematic files?

It looks wrong regardless of the file content. You mentioned before
that the file format specified exact \n bytes. If so, then the
sys.stdout.write("\n") line (and the earlier write of \n, as well as
any \n in the file content) will get translated to \r\n unless
sys.stdout has been set to binary mode *which is not the default* on
Windows.

The code needs to use the setmode incantation I posted before on
sys.stdout, before any writes take place.

It looks like all of the code involved has been written without taking
the distinction between text and binary mode opens into account
(typical of Unix-centric code, where text and binary have identical
behaviour). So a check of any file open calls, to make sure they use
"wb" and "rb" rather than plain "w" and "r", would also be in order.

Paul.



More information about the bazaar mailing list