Till now we are using CVS as part of our development environment,
in situation, where part of our developers work on Windows, while
the other, greater part of them work on FreeBSD. Both parts work
in the same project and with the same code but with native development
tools, some of which on Windows cannot work with Unix-style line endings
(LF) and require CR-LF. Unix developers, of cause, don't like CR-LF,
they want LF.
So, Windows CVS client (Cygwin) smartly solves this collision for us, since
it can translate Unix LF to Windows CR-LF during checkout or update
process, and in the reverse direction during code commit.
Now I've tested in or work process SVN 1.6.1: The repository (svn+ssh://) was
built on FreeBSD server, and clients were on Windows and FreeBSD.
Windows client was CollabNet client command line or Cygwin's - results
was the same (we cannot use GUI clients since the need in automatization).
As I've read in the SVNbook (red-bean)
- I can tune Subversion so, that when our code is committed under Windows -
CR-LF will be translated to LF, so Unix developers will be happy.
I can select the commit mode: to keep CR-LF in the code forever, to keep LF
forever or to use "native" line endings.
It was very pity for me, that all this tuning works only for commit operation,
not for checkout or update.
In other words: if Unix developer commits some code - Windows developer
cannot receive it with Windows line endings even if this file has svn:eol-style=native
This behavior contradicts to the description of "native" svn:eol-style property in the SVNbook,
but it was that I've seen in my testing.
Is there any solution?
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-16 21:28:16 CEST