> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 13 December 2001 11:08
> I'd like to vote for Bruce's plan.
+1 (mostly).
> 1) the repository receives consistent line endings, which assists all the
> various access mechanisms to the data that resides there
If you mean, consistent line endings for the same file, then: yes.
> 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
I think we are confusing eachother with the line endings property and what
it means. In my view it means: the eol style the file has in the repository.
This property can be used by the client to see if it needs conversion to
native style (and if it needs converting back). Ie. if it is different,
convert to native style.
> 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.
'none' doesn't have to be the default per se. I would like to opt for a
configure option in a svn config file somewhere, where you can set the default.
Here, 'native' would make sense, in that it sets the eol prop to the native
style of the client (be it CR, LF or CRLF). This way the combination of the
first commit with the config of the client doing the commit determine what
the style will be set to.
Also, the type of a file is already set default to binary, which should
be enough to protect against direct corruption. If users set the file type
to text, we have to assume they know what that means.
> 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).
I'm assuming you mean LF.
To me, the 'native' property looks like it could go. The same can be achieved
by setting the prop to 'LF'.
> 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.
Like above, I have a different interpretation of the eol property. Conversion
will occur when the native style is different than the style in the repos.
I do think that svn _export_ should do no conversion and just give back the
style from the repos. This will make the distro making pains go away AFAICT.
> 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
Sander
---------------------------------------------------------------------
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:52 2006