Comment 1 by Richard Hopkins, Sep 10, 2012
Add new test to check for garbled output from `mtn cat` The original issue was found using Java to read from the monotone process stdout on a Windows XP system, but was also reproduced using `mtn cat FILENAME > FILENAME`. However, on Linux (only tested on SUSE so far) no lines are garbled, even with newlines. I think the culprit is 'dump_file' which uses '<<', and the documentation states it performs formatting, where as 'put/write' perform no formatting. Whilst `mtn cat FILENAME > FILENAME` can be expressed as `mtn revert FILENAME` which works correctly and does not garble new lines (even on Windows), my opinion is that it should still work. The intention is to get the full original version, and `mtn cat FILENAME` is quicker to type and more efficient than using automate commands to fetch the workspace manifest, then request the content given a file_id. An example usage is using `mtn cat FILENAME` from a NetBeans IDE integration plugin, as NetBeans only needs the full original text of a file and automatically works out a diff, shows editor markers in the margin etc when in an editor window. The current plugin uses `mtn cat FILENAME` which works on Linux regardless of newlines in files, but fails on Windows when the file has Windows newlines (CRLF).
Comment 2 by Stephen Leake, Sep 11, 2012
'mtn automate get_file_of FILENAME' is a direct replacement for 'mtn cat', and does not have the problem.
Comment 3 by Richard Hopkins, Sep 11, 2012
Well spotted, I missed that automate command but I will use that from the NetBeans plugin regardless. Your patch on the mailing list looked like what I had though, so I don't know how to fix `mtn cat`.
Comment 4 by Richard Hopkins, Oct 30, 2012
There's another related issue. When trying to merge-3 a file on Windows that contains Windows newlines (CRLF) and has a conflict, the files to compare and merge interactively have the same problem, so every other line is blank. I tested on Windows XP and diffuse 0.4.6. As a workaround I copied 'temp_file' from 'std_hooks.lua' into my workspace 'monotonerc', but provided 'rb+' (binary mode) to the file open call. This fixes the file contents in diffuse, but then breaks the commit message when firing up notepad; notepad only handles CRLF. As a workaround for the notepad issue during commit I downloaded Notepad2, added it to PATH, and set EDITOR to Notepad2.
Sign in to reply to this comment.
Reported by Richard Hopkins, Aug 19, 2012
Steps to reproduce the problem: ------------------------------- 1. Create a test file 'test.txt', UTF-8, Windows newlines (CRLF) with the numbers {1,2,3,4} each on a new line. 2. Add the file and commit it. 3. Execute mtn cat test.txt > test.txt 4. View test.txt again, there will be extra newlines in between each number. Expected result: ---------------- The file should be exactly the same. Actual results: --------------- The file has extra newlines in between each number. Output of `mtn version --full`: ------------------------------- monotone 1.0 (base revision: unknown) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 3) on ia32 (level 15, rev 19458) C++ compiler : GNU C++ version 4.5.2 C++ standard library: GNU libstdc++ version 20101216 Boost version : 1_46_1 SQLite version : 3.7.5 (compiled against 3.7.5) Lua version : Lua 5.1 PCRE version : 8.12 2011-01-15 (compiled against 8.12) Botan version : 1.8.11 (compiled against 1.8.11) Changes since base revision: unknown