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
I consider Greg Hudson's proposal to be quite nice, but for the flip-flop
and the resulting "varying view" for other tools.
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: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:52 2006