Talden wrote:
> Can we at least close this off for the general readership of this list.
>
> 1. It's demonstrable that any single scheme to normalise EOLs in a
> mixed EOL 'text-file' has the potential to change the semantics of the
> file.
>
> 2. Removal of the EOL facility isn't going to happen and there is no
> deterministic manner in which you can normalise a file with mixed EOLs
> without risking a change in semantics.
>
>
> Options seem to be:
>
> a. Do not allow the particular file to added as text or at least do
> not allow it to be added with EOL conversion. This needs to be a user
> gesture rather than a client rule-set.
>
> b. Have subversion refuse to set the EOL conversion property for files
> added that demonstrate inconsistent EOLs. This can be a client rule
> rather than a user gesture - feedback is required to indicate that the
> rule has been applied. CAVEAT: This then causes problems for
> committing changes to existing files with the EOL property set if the
> change contains newly inconsistent EOLs (an assumption could be made
> given the platform and EOL property value but this may not always
> produce expected results).
c. Allow the user to specify ahead of time that non-native EOL's may
be normalized even if the transformation might not be reversible to an
identical binary. These aren't binary files. If your end target is a
different platform it may be totally irrelevant whether or not a
checkout back to the initial platform would or would not produce a file
that is an identical binary. It may never come back there anyway.
I fail to see how refusing to process a file is useful to anyone.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 6 00:33:39 2007