+1 on Greg Hudson's latest proposal -- and I think we're now ready to
Actually Do It. :-)
It's clear that no solution is perfect, because doing eol conversion
raises some inherently unresolvable questions. But my sense from
recent discussions is that everyone here can live with the choices
this proposal makes; also, it follows the Principle Of Least Surprise,
and is highly unlikely to damage data unfixably.
Below I'll quote his proposal, with a few annotations reflecting my
understanding of certain points, just to make sure.
If you have a *violent* objection, please post; otherwise, please do
not. We're looking for liveable consensus now, not further
refinements that would help some border cases and harm others. :-)
> 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.
My assumption is that "in the working copy" means both text-base and
working file, for the sake of an efficient is-modified-p test, and
since the repository file is just an automatic transform off the
text-base anyway.
If that's what you meant, then incoming svndiff has to be applied to a
deconverted tmp file, which then becomes the new text-base. No
problem.
Otherwise, then the is-modified-p check has to be tweaked in a way
that will make modifiedness checks a lot slower in some cases.
> 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.
The second sentence of the above paragraph isn't about allowing
mixed-style files. It's saying that if the entire file is native
format, allow that (and transform when necessary), OR if the entire
file is in the requested style, then allow that too. The latter
situation could happen if someone used a LF-style tool under Windows,
for example, so that when an LF-style file got saved, the whole thing
would be LF-style now, not native style. No reason to disallow this.
Right?
> On checkout, we translate LF -> <native newline style> if newline-style
> is native; otherwise, we leave the file alone.
Yup.
> 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.
Agree. Let's wait and let real-life use cases drive how we do mass
enablings.
I don't see any need for any of the "Variations" right now. Let's see
how the above works first.
-Karl
> 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