bugmonotone - 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: 

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 Levitte <rlevitte>
Group administrator
Mon 13 Jun 2005 05:51:36 PM UTC, original submission:  


when reading


I see that by default monotone does no line ending conversion.

I am looking for an alternative to subversion's "svn:eol-style=native" - a property used to mark files that should have the platform-native eol. I've found the hook |get_linesep_conv| but that would require each and every user separately determine and set the files. Is there anything that can be added to the database to make the information about the prefered eol-style for a file distribute in the same matter as the file itself? Maybe some cert? Or something in .mt-attrs?


graydon's response:

probably selecting behavior off of the "encoding" attribute (or a separate EOL one, since this is a related-but-different aspect of the encoding), subject to user override, will be ok. we need to try a few variations on the idea and revisit this. if you'd like to enter a bug, I would like to make the results both technically satisfactory and also "pleasant to use".


Zbynek Winkler <zwin>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by tommyd (Updated the item)

    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.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-30 tommyd Assigned torlevitte None
    2006-02-01 rlevitte Assigned tosircus rlevitte
    2006-02-01 rlevitte Assigned toNone sircus

    Back to the top

    Powered by Savane 3.12