Stefan, Les, thank you for encouraging me to continue my experiments.
The problem has solved. Some questions remains - see below.
> Cygwin has its
> own oddness, but it doesn't matter with cvs.
Exactly - Cygwin's mount feature (CR-LF translation) works for it's cvs client, it was not cvs native feature.
> Perhaps you
> committed, then set the property?
Yes, that was the case. But how can I set the property on file before it's first commit?
> Even then, it should be
> adjusted on the next commit.
Suprisingly for me, now it works! Yesterday it didn't worked, possibly there was some mistake
in subversion server repository creation or configuration. Today I've created repository from scratch.
The other possible reason for my problem was my experiments with auto-props configuration settings.
> I think you are seeing a cygwin
> issue where it makes the svn app think it is on unix.
Now I am working with CollabNet Windows binaries since Cygwin's svn client makes
Russian filenames unreadable (in contrast to Cygwin's cvs client). CollabNet's client works fine.
Now for me remains two questions (actually - one question and one answer)
1. Can I glue svn:eol-style=native property to some svn folder, so that any new
file commited to it - will receive the same property automatically - regardless of
auto-props settings absence in per-user svn config?
2. Under Windows CollabNet's client:
I want to set mime-types-file option in my %APPDATA%\Subversion\config file, to specify
auto property svn:mime-type for newly committed files by it's filename extensions.
I've placed the file subversion.mime.types in the same folder:
%APPDATA%\Subversion\subversion.mime.types
(file was received from Apache configuration from Unix server)
and specify
mime-types-file = mime-types-file = C:/Documents and Settings/username/Application Data/Subversion/subversion.mime.types
(it is rather strange for windows user, that such long filename with spaces in the path shouldn't be enclosed in quotas "...")
The same action on Unix machine works fine: comitted *.doc file receives application/msword
property. Under windows - it doesn't.
The source of that problem was in subversion.mime.types file format:
a. It's file format is not well documented in SVNbook
b. Original Apache file has LF line endings, and when I've tried it under Windows -
it silently does not work.
So, after I've recoded this file to Windows CR-LF line endigns - it begins to work!
It will be pleasant, if this explanation will be included in the next version of SVNbook,
better yet - if SVN client config files will be correctly parsed regardless of line ending style
under all platforms (so it will be possible to redistribute them).
Best regards,
Alexey Ivanov
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Saturday, May 16, 2009 11:49 PM
> To: Alexey Ivanov
> Cc: users_at_subversion.tigris.org
> Subject: Re: Mixed Unix-Windows development
>
> Alexey Ivanov wrote:
> > Hi,
> >
> > 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.
>
> All cvs operations default to native line endings unless you
> tell it to handle the file as binary '-k'. Cygwin has its
> own oddness, but it doesn't matter with cvs.
>
> > 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)
> >
> http://svnbook.red-bean.com/en/1.5/svn.advanced.props.file-portability
> > .html#svn.advanced.props.special.eol-style
> > - 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 property.
> >
> > 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?
>
> That doesn't sound right. If you set eol-style=native before
> committing
> (or have it set by a cvs2svn conversion or auto-props), then you
> should get native line endings on checkouts, updates, etc.
> Perhaps you
> committed, then set the property? Even then, it should be
> adjusted on the next commit. I think you are seeing a cygwin
> issue where it makes the svn app think it is on unix.
>
> --
> Les Mikesell
> lesmikesell_at_gmail.com
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2284852
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-17 02:32:11 CEST