Re: line-ending conversion and keyword substitution

I'd like to vote for Bruce's plan.

1) the repository receives consistent line endings, which assists all the
   various access mechanisms to the data that resides there

2) people seem to say "but the repos shouldn't munge what is committed."
   well, the *repository* doesn't munge anything. The client does any
   necessary work. It is simply committing a canonical version.

3) re: bruce's final point: you *do* want to be able to set the line endings
   to a fixed value (e.g. to CRLF for a .dsp or .dsw file). The choices for
   the line endings property would be: none, native, CR, LF, CRLF

4) all files default to "none" unless specified otherwise. it is possible
   that if we detect a mime type of "text/*" that we set it to "native".
   Note that *any* determination should have an easily explainable
   heuristic, otherwise people will never really know what is going to
   happen on any particular add/commit.

5) if a file has "native" type, then it goes into the repos as CR style
   (defined as the canonical repos style). this may imply some conversion
   from non-CR clients (win, mac).

6) note: CR, LF, CRLF are a lot like "none" in that no translation ever
   occurs. it is debatable whether they need to occur. the mime type tells
   us these are text files, thus subject to proper application of a context
   diff.

I consider Greg Hudson's proposal to be quite nice, but for the flip-flop
and the resulting "varying view" for other tools.

Cheers,
-g

On Wed, Dec 12, 2001 at 08:20:58PM -0800, Bruce Atherton wrote:
> At 07:13 PM 12/12/01 -0500, Greg Hudson wrote:
> >Let's say I'm on Windows, and we're using your newline proposal. I
> >create my no-vectors graphic file, save it, and check it in. Let's say
> >the initial contents are "VEC\n", which would be a little odd,
> >especially for a Windows program, but this is a binary format; it could
> >be anything. Then, next week, I check out the file. Even though it
> >came from Windows, my client transforms the file contents to "VEC\r\n",
> >because it has no idea where the file came from; it just thinks it looks
> >like a Unix text file.
>
> Well, no. As we discussed earlier, it wouldn't make sense to set
> line-ending-style to "native" for a file that didn't have any native line
> endings. It's style would get set to "none", and no transformations would
> be done on it.
>
> I guess I missed that behaviour in my proposal though, didn't I. Ok.
> Proposal Part Deux.
>
> 5. The line-ending-style should by default be set to "native" only if the
> file type is considered "text' as opposed to "binary" (according to
> heuristics discussed elsewhere) AND the file contains line endings that are
> appropriate for the platform it is being checked in from AND it contains no
> line endings that are inappropriate for the platform. Otherwise the
> line-ending-style should be set to "none". The user can override this as
> they see fit, of course.
>
> 6. If a file has a line-ending-style of "none", then none of the line
> separator alterations discussed in point 2 will ever occur. That means that
> the reverse alterations on a commit will likewise never occur.
>
> As an aside, there has been some discussion about setting the
> line-ending-style value to the platform, such as "unix", "dos", or "mac",
> or to the sequence of characters that make up the line separators, but I
> don't see the point here. The question you are trying to answer is whether
> a line-ending conversion will occur or not. The "native" and "none" should
> tell you everything you need to know on that score. For efficiency (or the
> ability to convert the line endings of a file already in the repository)
> you may want to set another property that indicates what line endings a
> file has in the repository (only necessary if the line-ending-style is
> "native", obviously), but that is an implementation detail.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org