You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Alexey Ivanov <al...@ashmanov.com> on 2009/05/16 19:23:18 UTC
Mixed Unix-Windows development
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.
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?
Best regards,
Alexey Ivanov
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2283587
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Stefan Sperling <st...@elego.de>.
On Sat, May 16, 2009 at 11:23:18PM +0400, Alexey Ivanov wrote:
> 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.
That should work. Even within the Subversion project we use this
every day and I've never heard of such issues.
It's hard to tell what is going wrong because you didn't describe
how you carried out your tests.
Stefan
Re: Mixed Unix-Windows development
Posted by Tom Browder <to...@gmail.com>.
On Sun, May 17, 2009 at 14:35, Andrey Repin <an...@freemail.ru> wrote:
> Greetings, Tom Browder!
Greetings to you, too, Andrey!
>>> Second... just to say that... svn+ssh is not very good idea, really. Requires
>>> too much care to manage. My personal opinion.
>
>> Care to elaborate? I do agree the book gives not much help for an
>> admin person wanting to use this method, but it seems easy to manage
>> once set up correctly.
>
> It's, very roughly, the same as using the file:// access method, as I
> understand it.
> You can just apply all issues of file:// to svn+ssh:// and re-read them with
> that in mind. The need of sane umask, the DIRECT ACCESS to the repository
> structure, and so on.
> If you do not have any special requirements for developers to have terminal
> access to the host managing SVN repository, you better use anything other than
> ssh tunnel.
On more reflection, you're correct. I've been using it since last
year after we converted from CVS and we have just a few users sharing
a repository. I went that route because it seemed so much easier
than setting up http access.
Regards,
-Tom
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2294733
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Tom Browder!
>> Second... just to say that... svn+ssh is not very good idea, really. Requires
>> too much care to manage. My personal opinion.
> Care to elaborate? I do agree the book gives not much help for an
> admin person wanting to use this method, but it seems easy to manage
> once set up correctly.
It's, very roughly, the same as using the file:// access method, as I
understand it.
You can just apply all issues of file:// to svn+ssh:// and re-read them with
that in mind. The need of sane umask, the DIRECT ACCESS to the repository
structure, and so on.
If you do not have any special requirements for developers to have terminal
access to the host managing SVN repository, you better use anything other than
ssh tunnel.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.05.2009, <23:32>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2293695
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Tom Browder <to...@gmail.com>.
On Sat, May 16, 2009 at 22:24, Andrey Repin <an...@freemail.ru> wrote:
> Greetings, Alexey Ivanov!
...
> Second... just to say that... svn+ssh is not very good idea, really. Requires
> too much care to manage. My personal opinion.
Care to elaborate? I do agree the book gives not much help for an
admin person wanting to use this method, but it seems easy to manage
once set up correctly.
Regards,
-Tom
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2292487
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 17, 2009, at 06:14, Alexey Ivanov wrote:
> Andrey,
>
>> To further clarify this moment, the svn:mime-type must be text/
>> <whatever>
>> for svn:eol-style to affect anything.
>> http://svnbook.red-bean.com/nightly/en/svn-
>> book.html#svn.advanced.props.special.mime-type
>> Look for the "Warning" block.
In my experience, Subversion will not let you set svn:eol-style if
the file is considered binary (by virtue of its svn:mime-type). Example:
$ svn propset svn:eol-style native foo.png
svn: File 'foo.png' has binary mime type property
$
> I think, that this could be some of my cases. Since I've trouble to
> attach mime-types-file in the Subversion config,
> mime types for files, with which I've worked, could be arbitrary or
> not set at all.
The mime types won't be arbitrary unless you've set them that way.
When you add a file, Subversion sets the file's mime type to whatever
your auto-props say to set it to. If you haven't defined auto-props
for this type of file, then Subversion sets the mime type to
application/octet-stream if it believes it to be a binary file,
otherwise it leaves the mime type blank and treats it as a text file.
If you somehow managed to set svn:eol-style on a binary file (perhaps
by loading a dumpfile, or by using the language bindings), I think
Subversion would happily convert the line endings of the file and
thus corrupt it. So you definitely should not attempt to set svn:eol-
style on a binary file.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2292078
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Mixed Unix-Windows development
Posted by Alexey Ivanov <al...@ashmanov.com>.
Andrey,
> To further clarify this moment, the svn:mime-type must be text/<whatever>
> for svn:eol-style to affect anything.
> http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.mime-type
> Look for the "Warning" block.
I think, that this could be some of my cases. Since I've trouble to attach mime-types-file in the Subversion config,
mime types for files, with which I've worked, could be arbitrary or not set at all.
The other reason for my problem could be: I've set svn:eol-style=native on already comitted file, but didn't commit
the property itself.
Now all my problems has solved.
I will send SVNbook improvement request for all these topics.
Best regards,
Alexey Ivanov
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2290709
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Andrey Repin!
>> 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.
> No, seriously, you got it absolutely wrong.
> It does not commit what, it check out what.
> If you set svn:eol-style to native your checkouts will have line-endings
> native to the system you've checked it out, but what is stored in SVN is a
> whole different question, not related to your issue.
>> It was very pity for me, that all this tuning works only for commit operation,
>> not for checkout or update.
> You must tell your developers to add files with proper properties (in case -
> svn:eol-style).
> Then it will work as you want.
To further clarify this moment, the svn:mime-type must be text/<whatever>
for svn:eol-style to affect anything.
http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.advanced.props.special.mime-type
Look for the "Warning" block.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.05.2009, <13:48>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2290209
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Andrey Repin <an...@freemail.ru>.
Greetings, Alexey Ivanov!
> 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.
No, seriously, you got it absolutely wrong.
It does not commit what, it check out what.
If you set svn:eol-style to native your checkouts will have line-endings
native to the system you've checked it out, but what is stored in SVN is a
whole different question, not related to your issue.
> It was very pity for me, that all this tuning works only for commit operation,
> not for checkout or update.
You must tell your developers to add files with proper properties (in case -
svn:eol-style).
Then it will work as you want.
> 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 not sounds right. Some logs to confirm your case?
> 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?
First, I think it'd be good to provide logs. A testcase may be.
Second... just to say that... svn+ssh is not very good idea, really. Requires
too much care to manage. My personal opinion.
--
WBR,
Andrey Repin (anrdaemon@freemail.ru) 17.05.2009, <7:19>
Sorry for my terrible english...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2287381
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 16, 2009, at 17:26, Alexey Ivanov wrote:
>> 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?
svn add somefile
svn propset svn:eol-style native somefile
svn commit somefile
Or, if you have set up an auto-props rule that matches somefile, then
the properties will be automatically set for you the moment you add
the file, and will thus be part of the first commit.
> 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?
No, there's no feature like that in Subversion. Use auto-props on the
client, and set up a pre-commit hook on the server to reject commits
that do not conform to your property policy.
> 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).
That's a good suggestion, but note that book feedback should be sent
to the book mailing list, which you can find under the "Feedback/
Contributing" heading on
http://svnbook.org/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2286055
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Mixed Unix-Windows development
Posted by Alexey Ivanov <al...@ashmanov.com>.
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@gmail.com]
> Sent: Saturday, May 16, 2009 11:49 PM
> To: Alexey Ivanov
> Cc: users@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@gmail.com
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2284852
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Mixed Unix-Windows development
Posted by Les Mikesell <le...@gmail.com>.
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@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2283799
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].