Hey all,
So in the latest 1.5.x revisions code is jalopy-formatted automatically on an mvn clean install. Is this by design? From Andrea's email on the 13th ("Closing GSIP #2) I had thought it wasn't supposed to work this way...
Since many of the files actually in the repository are not in jalpoy-formatted format this means that an svn diff after a fresh checkout and mvn clean install gives LOTS of different files. Should someone check-in a jalopy formatted version of these files, or is something goofy going on with my config?
Steps to duplicate my issue:
1) Check out a FRESH 1.5.x
2) Run "mvn -Dmaven.test.skip clean install"
3) Run "svn diff | grep "\.java" | grep Index:"
4) Note the large number of modified files which were actually just jalopy formatted.
Thoughts? Right now I'm going to comment out auto-formatting on install and proceed (in my root pom) . I think auto-formatting should be removed from the install goal and left to run "by convention" before a checkin.
--saul
Hi Saul,
One thing that is very important ( as we just recently found this out ) is that you have the right subversion config file. Without it newlines will be handled differently accross platforms and when you do a format, every file will come up as being modified due to new lines being off.
Using the config file is documented here.
http://docs.codehaus.org/display/GEOSDOC/2+Subversion
One thing we should also do is set the svn:eol-style property to native for all java files in the repository. This should also prevent the conflicts if someone checks out without first configuring subversion.
-Justin
Saul Farber wrote:
Hey all,
So in the latest 1.5.x revisions code is jalopy-formatted automatically on an mvn clean install. Is this by design? From Andrea's email on the 13th ("Closing GSIP #2) I had thought it wasn't supposed to work this way...
Since many of the files actually in the repository are not in jalpoy-formatted format this means that an svn diff after a fresh checkout and mvn clean install gives LOTS of different files. Should someone check-in a jalopy formatted version of these files, or is something goofy going on with my config?
Steps to duplicate my issue:
1) Check out a FRESH 1.5.x
2) Run "mvn -Dmaven.test.skip clean install"
3) Run "svn diff | grep "\.java" | grep Index:"
4) Note the large number of modified files which were actually just jalopy formatted.
Thoughts? Right now I'm going to comment out auto-formatting on install and proceed (in my root pom) . I think auto-formatting should be removed from the install goal and left to run "by convention" before a checkin.
--saul
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:1004,45d60da1189127731818748!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Hi Saul,
One thing that is very important ( as we just recently found this out ) is that you have the right subversion config file. Without it newlines will be handled differently accross platforms and when you do a format, every file will come up as being modified due to new lines being off.
Using the config file is documented here.
http://docs.codehaus.org/display/GEOSDOC/2+Subversion
One thing we should also do is set the svn:eol-style property to native for all java files in the repository. This should also prevent the conflicts if someone checks out without first configuring subversion.
It's not exactly like this. The configuration files makes it so that
properties are automatically applied on newly committed files.
On those that have been already committed the change needs to be performed by hand (or automatically, using a find xxx -e yyy command
on unix). We do have some 240 files without the right attributes,
that's why we are seeing troubles.
Cheers
Andrea
Hmm, I am a little confused. I thought the property in the config file was applied for all files that are checked out. Perhaps my understanding is off ( would not be the first time 
).
Regardless, I can run the set property command on all the files.
Andrea Aime wrote:
cts if someone checks out without first configuring subversion.
It's not exactly like this. The configuration files makes it so that
properties are automatically applied on newly committed files.
On those that have been already committed the change needs to be performed by hand (or automatically, using a find xxx -e yyy command
on unix). We do have some 240 files without the right attributes,
that's why we are seeing troubles.
Cheers
Andrea
!DSPAM:1004,45d6ea75295687731818748!
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira ha scritto:
Hmm, I am a little confused. I thought the property in the config file was applied for all files that are checked out. Perhaps my understanding is off ( would not be the first time ).
http://svnbook.red-bean.com/en/1.1/ch07.html
"enable-auto-props
This instructs Subversion to automatically set properties on newly added or imported files. The default value is no, so set this to yes to enable Auto-props. The auto-props section of this file specifies which properties are to be set on which files."
Cheers
Andrea