On Thu, Dec 13, 2001 at 07:44:48PM -0500, Greg Hudson wrote:
> 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.)
I totally agree. Another way to look at this is that if a file
has mixed separators, it's a binary file. Of course, that means
an O(n) scan for determination of "binaryness", but maybe we should
do that anyway (the current heuristic only looks at the first bit
of the file).
>
> 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.
>
I proposed a solution on IRC to handle this case. It seems to me that
what we want here is something like a "view", i.e., a WC-specific set
of properties. What if we embed the WC-desired CR/NL/CRNL semantics
*in* the request URL?
http://svn.collab.net/CR/repos/svn/trunk
http://svn.collab.net/NL/repos/svn/trunk
http://svn.collab.net/CRNL/repos/svn/trunk
And then let an apache module sort out the rewriting?
Alternatively, we could do:
http://svn.collab.net/repos/svn/trunk?record=CR
http://svn.collab.net/repos/svn/trunk?record=NL
http://svn.collab.net/repos/svn/trunk?record=CRNL
And let mod_dav sort out the rewriting. I'm not sure
if all DAV tools can include a query-string, though.
Another alternative would be to use an SVN branch that
had alternate default properties:
http://svn.collab.net/repos/CR/svn/trunk
http://svn.collab.net/repos/NL/svn/trunk
http://svn.collab.net/repos/CRNL/svn/trunk
This would require server-side implementation of the
separator semantics (which goes against the current
proposals, but does clean up this mess). Also, these
branches would probably need to be read-only.
Comments?
--ben
---------------------------------------------------------------------
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