On Sun, 2006-01-29 at 20:54 +0100, Richard Levitte - VMS Whacker wrote:
> The two line endings returned by get_linesep_conv() are only used when
> writing the files. When reading them (at least when reading them from
> the workspace), monotone is trying to be smart and looks for all kinds
> of line ends when it splits lines. \r, \n and \r\n are treated the
> same.
That's exactly the problem. It shouldn't be smart here. Because if I
said my linesep is '\n' you should trust me. This will work in 99%
cases. 1% is a case when you used '\r\n' and deleted one of these
leaving only '\r' or '\n'. How the f. that possible??? That not 1% it is
a probability 10^-6 case I guess.
On the other hand having get_linesep_conv() return {db=LF, working
copy=CRLF} worked for binary is a much probable scenario. For me it
happened at least and I spent an hour trying to understand WHY the hell
monotone wants to patch qwe.fig if I didn't touch it. When I figured out
that conversion is done in such a strange way I thought "possibly this
for some reason, otherwise this must be fixed". I wrote to list and
still can't hear the reason.
> For the moment, there is no 'linesep_old'. That's not how it is
I mean in terms of function line_end_convert() there is linesep_old
(which is working_copy_linesep on read-from-working copy and db_linesep
on write-to-working copy).
> If you want to focus on something, I'd focus on getting monotone to
> handle binary files in a better way (as in, at all).
Doing a graceful conversion is I think one of the steps in "getting
monotone to handle binary files in a better way". This shouldn't happen
(conversion) but if it happened at least changes don't go outside of one
screwed up working copy.
Cheers,
-up
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
