monotone - Bugs: bug #13390, Line ending conversion
You are not allowed to post comments on this tracker with your current authentication level.
bug #13390: Line ending conversion
Submitter: | Zbynek Winkler <zwin> | ||
Submitted: | Mon 13 Jun 2005 05:51:36 PM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | feature request | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | ||
mtn version --full: |
|
Wed 01 Feb 2006 08:09:03 AM UTC, comment #1: |
Richard Levitte <rlevitte>![]() |
Mon 13 Jun 2005 05:51:36 PM UTC, original submission:
Hello,
|
Zbynek Winkler <zwin> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
As soon as we deal with this, we also MUST deal with binary files internally, and we MUST mark them as such so they are consistently kept binary, no matter what.
Getting back to line endings, there are a few things that aren't quite right:
1. the internal line ending should be constant, the user should not be able to change it via get_linesep_conv as it is today. All that should be possible for the user to configure is what should be regarded as the line ending in text files in the workspace.
2. monotone currently adds a line ending at the end of a text if it's missing. This is because split_into_lines() currently has no semantics at all to show that, and join_lines() assumes that every line should end with a line ending, even the last one. This is easy to fix in itself, but it affects everything that uses split_into_lines(), and there are quite a number of routines that do exactly that.
3. monotone currently splits lines at ANY known line ending, so it will split at all CR, LF and CRLF. I'm not at all sure this is bad, but it's being discussed quite heavily on the mailing list.
/Richard