On Fri, 2001-12-14 at 12:36, Ben Collins-Sussman wrote:
> Sorry, what is a 'source-format newline'?
I guess I played a little fast and loose with terminology there.
Let's say we're transforming CRLF to LF. CRLF is what I meant by
"source-format newline". If there are any CRs or LFs in the file which
aren't part of a CRLF pair, then the transform is not reversible.
> So, given that we're implementing a transform-on-commit system, the
> only clarification left is how metadata fits in.
Alright, I'll make a proposal which is like yours but (in my opinion) a
little clearer. First, let's look at the different use cases:
1. The most common case--text files which want native line endings.
These should be stored in the repository using LF line endings, and in
the working dir using native line endings.
2. Binary files. These files we don't want to touch at all.
3. Text files which, for one reason or another, want a specific line
ending format regardless of platform. These should be stored in the
repository and in the working directory using the specified line
ending. We probably don't have to worry so much about data safety for
these files since a particular, odd behavior has been specified for
them.
There are, of course, a hundred different ways we could arrange the
metadata. I propose an "svn:newline-style" property with the possible
values "none", "native", "LF", "CR", and "CRLF". The values mean:
none: Use case 2. don't do any newline translation
native: Use case 1. Store with LF in repository, and with native line
endings in the working copy.
LF, CR, CRLF: Use case 3. Store with specified format in the
repository and in the working copy.
On commit, we apply the following rules to transform the data committed
to the server:
If newline-style is none, do nothing.
If newline-stle is native, translate <native newline style> -> LF. If
we notice any CRs or LFs which aren't part of a native-style newline,
abort the commit.
If newline-style is LF, CR, or CRLF, translate <native newline style>
-> <requested newline style>. If we notice any CRs or LFs which aren't
part of a native-style newline and aren't part of a requested-style
newline, abort the commit. If the commit succeeds, apply the <native
newline style> -> <requested newline style> translation to the working
copy as well, so that it matches what we would get from a checkout of
the new rev.
On checkout, we translate LF -> <native newline style> if newline-style
is native; otherwise, we leave the file alone.
For now, let's say the default value of svn:newline-style is none. In
the future, we'll want to think about things like how to enable
newline-translation over the whole repository except for files which
don't appear to be text.
I think that's a complete proposal. Some possible variations:
Variation 1: If newline-style is native, on commit, translate <first
newline style seen> -> LF. If we see any CRs or LFs which don't match
the first newline style seen, abort the commit.
Variation 2: If newline-style is native, before commit, examine the
file to see if it uses only the native newline style. If it doesn't,
set the newline-style property to "none" and commit with no translation.
Variation 3: Combine variations 1 and 2; if newline-style is native,
then if before commit, examine the file to see if it uses a single
consistent newline style. If it does, translate <that newline style> ->
LF; if not, commit with newline-style set to "none" and no translation.
Variation 4: If newline-style is native, then on commit, we edit a
property "svn:newline-conversion" to something like "CRLF LF" to show
what conversion we did. This enables mechanical reversal of the
translation if the file is later determined to be binary. (Particularly
useful with variations 1 or 3 where the transform might not be obvious
from the platform where the file was checked in.)
---------------------------------------------------------------------
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