I have some new thoughts on newline translation, after talking to some
MIT friends about it.
1. We can avoid irrevocably destroying data if we make sure all
newline translations we do are reversible. A newline translation
is reversible if there are no CRs or LFs in the file which aren't
source-format newlines.
This means we can go back to Ben's proposal, and as long as we add
this safety, we don't have to worry about destroying anyone's
engine designs. If the engine design was made on Windows and
happens to only contain CRLFs, they will get translated to LF on
checkin, but translating LF back to CRLF will restore the file. If
the engine design contains CRLFs mixed with LFs and CRs, we can
error out, or decide that the file must be binary after all.
(If we want to go a little overboard on safety, we could make the
client library set a property on each commit saying what newline
translation was done, if any. Then it would be easy to retrieve
the exact contents of the committed file by reversing the
translation. I don't think this is necessary, though.)
2. Unfortunately, as I noted in one of my many other messages today,
*none* of the schemes presented so far will robustly handle tools
which access the repository through DAV or libsvn_fs, if the tools
run on varying platforms and aren't forgiving about newlines. In
order to do that, we have to actually add the concept of a text
file to the FS layer.
Here is what I propose:
* For now, we implement Ben's scheme, with the proviso that we never
do a non-reversible newline translation. (This totally messes up
Karl's poll because it didn't include Ben's scheme.) The
repository gets a global format of LF.
* Tools which use DAV or libsvn_fs must be able to handle LF line
separators. All Unix tools will be okay. Most Windows tools will
probably also be okay because they know they're getting data over
the net where not everyone uses the same newline style. (And most
Mac tools will probably be okay because MacOS X is already
schizophrenic about newlines.)
* If the above turns out to be a problem, we can talk about changing
the concept of the FS layer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:53 2006