problems with encodings for signed commits

[Aaron Bentley]

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

Dafydd Harries wrote:
> Ar 29/12/2005 am 00:24, ysgrifennodd Aaron Bentley:
> 
> I think we're using different versions of bzrtools. 

Ah.  I assumed you were using Robert Collins' version, because you're
from Canonical.  Robert will soon be getting his branch into a mergeable
state so this confusion will go away.

> If  .decode('ascii', 'replace') was used, it would have mangled the log
> (replacing all non-ascii characters with \ufffd), which didn't happen. In this
> case, at least, decoding from UTF-8 was the right thing to do, even if it was
> being done in the wrong place.

No, it's the wrong thing to do, because baz logs have no defined
encoding.  In the absense of any information, we must not guess.

Yes, the user could force an encoding, but imports using different
encodings would not be interoperable, whereas currently, independent
imports are interoperable.

>>This is bogus.  If Commit.commit gets a bytestring, it should treat it
>>as ascii-- there's no defined encoding.  Assuming that this bytestring
>>is in the user encoding is not right.  This should be done in
>>cmd_commit, where we know that the bytestring came from the user, and
>>therefor the user's encoding applies.
> 
> 
> That will work if I'm importing from a baz archive that's using the same
> encoding as I am, but there's no way of knowing that that's the case.

cmd_commit is not used when importing from a baz archive.  It's
commandline UI functionality.  We can be quite certain of the correct
encoding when bzr is invoked from the commandline.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDtB9G0F+nu1YWqI0RAvEyAJ48DTyLNBv54vpwWUwvoFrK5HEc+ACfSPjK
bjZxVWtbNiHK8r0Nuwb6SWA=
=AiOl
-----END PGP SIGNATURE-----