Actually, thinking about it, I was wrong here, only committers are concerned. 
So only them must use a Subversion 1.8 client

Jacques


Le 27/07/2016 à 12:35, Jacques Le Roux a écrit :
Actually, since we get new committers now and then and their are able to create new files I have a warning every 6 months which says "Check Java files, have all svn:eol-style=native" (I totally forgot that because I assume the machine knows it and warns me ;))

I could extend that to all files (at least the most prominent types), I'll 
see...

Jacques


Le 27/07/2016 à 11:44, Taher Alkhateeb a écrit :
Okay, it seems from the documents that you provided we will not feel the
impact, and this would actually improve the situation by ensuring that
files are checked in with the right EOL and we don't need to go back and
forth over the correct EOL encoding.

If you didn't face any problems while converting, then I would suggest to
apply this setting on the entire repo to have a permanent solution for
everything. I faced a few problems in the past with some JavaScript
libraries but maybe that was due to a different cause, not sure.

On Wed, Jul 27, 2016 at 12:22 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Taher,

Actually a svn repo *always* stores files in *nix EOL format. You don't
have to worry about that.

How it is when you checkout or update your working copy depends on the
platform you use

This is clearly explained at the bottom of
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html

I explained that a bit in r1753400

Of course you need to use a Subversion version > 1.7, but nowadays else
would not make much sense (vulnerabilities, etc.)

Jacques



Le 27/07/2016 à 11:11, Taher Alkhateeb a écrit :

Hi Jacques,

What does this setting imply? Does it imply that all users regardless of
their OS will push LF characters for EOL to the repository? And does it
also mean that If I checkout a working copy that I will not find strange
EOL characters (^M) in my files?


Taher Alkhateeb

On Wed, Jul 27, 2016 at 12:07 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

BTW if nobody disagree, I'd like to follow the suggestion I made in the
last message of the linked thread.

In other words, use


http://subversion.apache.org/docs/release-notes/1.8.html#repos-dictated-config


http://blogs.collab.net/subversion/the-road-to-repository-dictated-configuration-day-2-autoprops

Then this problem would be over. No longer need to check from time to
time
that concerned files, have svn:eol-style=native property set
This imply that all OFBiz users use svn > 1.7, but we can inform them, et
voilà

Opinions?

Jacques



Le 27/07/2016 à 10:50, Jacques Le Roux a écrit :

It's not a workaround, it's how things should work according to Apache
Subversion documentation, but I missed one part.

I was there before, see http://markmail.org/message/fnvmt4fapgowtaux

So please wait I also need to set the svn:properties of the *.gradle
files and commit them in the repo

Jacques


Le 27/07/2016 à 10:25, Taher Alkhateeb a écrit :

Hi Jacques and All,
I noticed in your commit r1754071 you mentioned a workaround for the
EOL
issue generated from your editor which I cannot understand. Right now
I'm
trying to commit some work for cleaning up the libraries and again I
face
the EOL issue (I updated my config file for subversion). What exactly
should I do here?

Regards,

Taher Alkhateeb






Reply via email to