On Oct 22, 2006, at 10:29, Peter Kahn wrote:
> In cvs it seems that the eol handling rules are that all files have
> eol-native unless the user check's them in with a commandline option
> to tell the system that it shouldn't be translated.
>
> In svn it seems that default eol handling is that all files are not
> translated unless the individual clients set the svn:eol-style
> properties to native.
>
> CVS - default, translate eol
> SVN - default, do not translate eol
>
> What was the rational for the change?
>
> Is it that most modern editors and tools seem to handle other-OSes eol
> and practice respect for a file's eol style (in an DOS eol file the
> editor puts DOS eols not unix)?
I believe it was that this feature of CVS has been responsible for
many people's binary files getting corrupted, and this not being
discovered until much later, sometimes after the original file is no
longer available, which is very frustrating. And I think there was a
thought that a revevision control system's job is primarily to retain
the file you checked in, not mangle it in some way. Better not to
mangle by default. Of course, if you want line ending translation,
you can set the svn:eol-style property on those files where you want
this translation done, and even configure auto-props to apply the
property automatically on certain types of files: for example, all .c
files. Yes, this is a client-side setting, but you can install a
server-side pre-commit hook to reject certain file types when they
are checked in without the svn:eol-style property, if you wish to do
that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Oct 22 19:51:30 2006