[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] the line-ending discussion
From: |
Graydon Hoare |
Subject: |
[Monotone-devel] the line-ending discussion |
Date: |
Thu, 02 Feb 2006 11:45:30 -0800 |
User-agent: |
Thunderbird 1.5 (X11/20051201) |
Hi,
I'm really surprised this thread has carried on so long and involved so
many harsh words. I also see a lot of over-design. I really only see two
situations which need differentiation:
1. Files you wish monotone to treat as a sequence of bytes.
2. Files you wish monotone to treat as a sequence of lines.
The reason for supporting case #2 is that many tools (diff, patch, our
diff-writer and auto-merger) work in terms of lines, and we like the
behavior of those tools.
Monotone will address these cases by marking one sort of file with an
attribute, and assuming a file is "the other case" when it lacks the
attribute. Observant readers will note that, given the mutual
exclusivity of cases, it does not matter which gets marked.
Implementation detail.
That leaves UI, which is where most of the debate is.
There are two debates in the UI space:
1. Whether to assume a new file is "lines" or "bytes" by default.
2. How to pick the line endings, when writing a "lines" file to the
workspace, and conversely which line ending to break on when
reading a "lines" file back from the workspace.
Different users have different, sensible preferences on these matters.
They are "policy" for each project. Monotone will have one default wired
into it -- my preference is "bytes" for #1 and "native" for #2 -- but
each project will have the ability to override that default once we have
a mechanism for storing project policy ("management branches").
Until such time as we have a mechanism for setting project policy, we
can add an FAQ entry about setting the attribute manually, with a
promise to move to a project-policy approach later.
Is this a clear enough position for everyone?
(Assuming we take off our "nit-picking overdesigner" hats and put on our
"simplicity-loving compromiser" hats)
-graydon