Bram Moolenaar wrote:

> > > Automatic LF to CR-LF translation always causes trouble somewhere.
> > 
> > I have never had a problem with CVS doing this.  I believe
> > the "trick" is to only mark 'native' those files which are
> > indeed text files.
> 
> Right.  So what if files aren't properly marked as text or binary?
And
> there always is a mistake somewhere (I recall there was an icon file
> that was broken for a year before someone discovered it should be
marked
> binary).

Normally, text files are recognized by Subversion itself.  It is
possible to add a validation that rejects the commit of a text file
which doesn't have the "svn:eol-style" property set.

> I've seen too many files with mixed line endings, this can be a real
> mess.  Especially Unix files that were edited in Visual studio.

Fortunately, Subversion rejects text files with mixed line endings if
you have set the "svn:eol-style" property.

> Also remember that files on a USB stick will never adjust to the
> computer you plug it into.  Systems must be able to deal with both LF
> and CR-LF.
> 
> There is only one solution eventually: Drop those CR-LF line
separators.
> It just takes a bit of time before all MS-Windows programs can deal
with
> them.

In the current Subversion repository, Edward L. Fox set "svn:eol-style"
to "native".  This means, on a Unix system you get LF line endings, and
on a Windows system you get CR-LF.  You can commit changes from both
systems without problem.  Subversion always stores LF line endings
internally, even when you commit from a Windows system.

But there are still problems with setting "svn:eol-style" to "native":

    - Bram's example of a USB stick.  If you are working on a MS Windows
      system and create a working copy on a USB stick, then plug it into
      a Unix system, your Subversion commands would get into trouble
      with the working copy on the stick.  (And vice versa.)

    - If you are working on a MS Windows system, you may also be using
      Cygwin.  The svn commands that come with Cygwin expand "native"
      files to LF line endings.  You may want to access the same working
      copy from a native Windows client like TortoiseSVN, which expects
      CR-LF line endings if "svn:eol-style" is set to "native".  Again
      you get into trouble.

      Note that this isn't an uncommon scenario.  I use TortoiseSVN most
      of the time because you can do lots of things with a few mouse
      clicks (example: looking recursively at all modifications you made
      to your working copy).  But for some things (like moving files to
      different directory), the "svn" command-line interface is much
      more convenient.

      (I finally solved this problem by deinstalling the Cygwin "svn"
      commands and adding the native commands from subversion.tigris.org
      to my PATH variable.)

    - If you are working on a Unix multi-user system, but have access to
      it from a Windows PC via an X client like Exceed (this is what we
      do in our company).  On the X window screen, you can use the Unix
      "svn" command from the shell.  But if you have mapped the Unix
      file system to your Windows PC as a network drive (via Samba), you
      may also want to access the same working copy from the MS Windows
      explorer with TortoiseSVN.  You run into the same problems as in
      the previous issue, but you can't solve it since you can't install
      a Subversion package that treats "native" line endings as "CR-LF"
      on Unix.

All the preceding scenarious can be summarized as:  When accessing the
same working copy by sharing the file system between different operating
systems, a setting of "svn:eol-style" to "native" still causes problems.

So I suggest to use a "svn:eol-style" setting of "LF" instead of
"native".  

I don't recommend this as a general method: "native" is more useful if
you don't have any knowledge about which editor is used.  I suggest it
only for the Vim sources.  Everyone editing them (on MS Windows) will be
using an editor that is able to handle LF line endings, I suppose.  Or
as Bram said:

> In the context of Vim I don't think we should worry about notepad
users.

Of course, files like Make_ivc.mak should get a "svn:eol-style" setting
of "CRLF" instead of "native", for the same reasons.

Any opinions to this?

- Servatius

------------------------------------------------------------------------
Servatius Brandt             Phone: +49 89 636-41504
Fujitsu Siemens Computers    Fax:   +49 89 636-48716
EP SW AD C++                 Email: [EMAIL PROTECTED]

Reply via email to