BTW we could maybe 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 need to check from time to time that all
Java files, and maybe others, have svn:eol-style=native property set
But this would imply that all OFBiz users use svn > 1.7
Jacques
Le 10/08/2015 18:53, Jacques Le Roux a écrit :
OK, after reverting Adam's commit (r1044202) at r1695126, I rather completed it
at r1695129. Now all Java files have svn:eol-style=native property set
Before my 2 commits, only 116 Java files were missing svn:eol-style=native. I guess those have been added by committers who are not using the OFBiz
svn config file on their machines since Adam forced the others at r1044202.
I guess, I mixed up 2 things: the initial checkout status in the working copy (all files with svn:eol-style=native use your platform EOL) and the
files added afterwards (I suppose they are not using your your platform EOL but the one they were committed with)
So please committers remember to use the OFBiz svn config file
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-CommittingChanges
Contributors, you should also use it as recommended in Guidelines at
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
Thanks
Jacques
Le 06/08/2015 17:34, Jacques Le Roux a écrit :
Oops, wrong button, I just wanted to say that I will revert this commit and
will then remove all remaining(?) svn:eol-style properties from the repo
Jacques
Le 06/08/2015 17:32, Jacques Le Roux a écrit :
Hi Adam,
From svn doc I see no reasons to force svn:eol-style property as you did at
r1044202 (see below)
As said at
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html
svn:eol-style is only a working copy feature, for instance:
|native|
This causes the file to contain the EOL markers that are native to the operating system on which Subversion was run. In other words, if a
user on
a Windows machine checks out a working copy that contains a file with an |svn:eol-style| property set to |native|, that file will contain
|CRLF|
EOL markers. A Unix user checking out a working copy that contains the
same file will see |LF| EOL markers in his copy of the file.
Note that Subversion will actually store the file in the repository using normalized |LF| EOL markers regardless of the operating system.
This is
basically transparent to the user, though.
So your commit has not effect on the repo where all is LF EOL anyway, nor on people working copies when they use our svn config file as explained
at https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices "Install the OFBIZ Subversion client configuration file"
It seems though to have an impact on working copies produced by users not-aware-of/not-using our svn config file. So I think this commit just add
confusion
I don't think this depends on Subversion version used locally (above doc is for
1.7, I use 1.8.11)
Jacques
Le 10/12/2010 03:40, [email protected] a écrit :
Author: doogie
Date: Fri Dec 10 02:40:02 2010
New Revision: 1044202
URL:http://svn.apache.org/viewvc?rev=1044202&view=rev
Log:
Setsvn:eol-style properly on all java files. This needs to be done on other text files as well, but that would cause undo conflicts in the
jquery branch(due to .js being heavily modified there). Also, some files were committed to the repository with DOS line endings; those are fixed
as well.
Modified:
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/AIMRespPositions.java
(props changed)
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/authorizedotnet/CPRespPositions.java
(props changed)
ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/securepay/SecurePayPaymentServices.java
(props changed)
