BUG: bundle testament: something wrong again

[Alexander Belchenko]

Alexander Belchenko пишет:
> I pull recent bzr.dev with latest fixes for bundle mechanism (revno.1850).
> 
> I try to merge my installer bundle to recent bzr.dev. And I have error:
> 
> D:\user\MyCode\bzr\devel\bzr.dev.win32.installer>bzr merge
> win32-installer.patch
> Inventory sha hash mismatch for revision
> bialix at ukr.net-20060629091547-540fc31b864d5b26.
> 5c326b591f5c2327965ce8b30ba4eef3c88bfa9
> e != be74bfd7c441d0cf69a4f5cdafe46690603f8459
> bzr: ERROR: Testament did not match expected value.
>         For revision_id
> {bialix at ukr.net-20060629091547-540fc31b864d5b26}, expected
> {c55348d1a8ade8f1ad01d1d67bbf572d99ed934e}, me
> asured
>         {fbf8a32677960e1247668db7ae2bfb8fa76dd0ef}
> 
> 
> Similar error was earlier, it was win32-specific. John was fixed this
> issue but now it arise again.
> 
> One note: this bundle was created 2 weeks ago. So, probably there is
> backward non-compatibility within one version of bundles (v.0.8)?

[Semi] false alarm. This bug caused by line-endings mangling.

Inside this bundle I have file start_bzr.bat that actually use CRLF
line-endings. But all other files LF-only. When this bundle send via
e-mail my Thunderbird interpret bundle as text file and erase
distinction between this two types of line-endings.

So I come into this problem with my patch. Right now I see only one
solution: make bundle completely binary to avoid mangling of
line-endings. E.g. store bundle inside gzip/zip archive for emailing them.

As I understand another solution for this problem (and this was 
discussed before, IIRC) is to make diff inside bundle only for review 
and store *all* actual revision text inside base-64 encoded section. 
(Now inside these sections stored only previous revisions).

--
Alexander