SVN merge takes "-x -w" arguments to ignore whitespace. I am not sure about updating.
-Andrew On Thu, Jul 3, 2008 at 4:39 PM, simon <[EMAIL PROTECTED]> wrote: > Sorry, but I think conflicts are now being reported when updating a > checkout dir for files where *all* of these were true: > * contains tabs > * did not have eol-style set to native > * was not first checked in from your native platform. > > I'll try to think of a nice way to automatically clean up those > conflicts.. > > Regards, Simon > > On Fri, 2008-07-04 at 00:04 +0200, simon wrote: >> By the way: >> >> * the detab.sh script is here: >> http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/scripts/detab.sh >> >> * I haven't touched tobago, trinidad or portlet-bridge. It's up to the >> developers of those projects to choose when/if they want to do this. >> >> I also fixed quite a few .java files that did not have eol-style set to >> native. People, could you please check that you have your >> ~/.subversion/config >> file set up correctly? >> >> Regards, >> Simon >> >> On Thu, 2008-07-03 at 23:11 +0200, simon wrote: >> > Ok, as people seem happy to see tabs cleaned up done I'm doing it now. >> > But I'm leaving trailing whitespace alone for now; there is less benefit >> > and it does touch a whole lot of files. >> > >> > To anyone who currently has checked-out directories with uncommitted >> > changes in them, I recommend running "detab.sh" *before* running svn >> > update. This will avoid having conflict markers inserted into all your >> > locally modified files. >> > >> > If you forget, do svn update, and end up with lots of conflicts then I >> > recommend: >> > * install svn 1.5.0 (if you don't have it already), then >> > * "svn resolve --recursive --accept mine-full ." then >> > * run detab.sh >> > >> > Regards, >> > Simon >> > >> > On Wed, 2008-07-02 at 22:14 +0200, simon wrote: >> > > Interesting question, Manfred. Here are the answers: >> > > >> > > Count of java files is done via: >> > > find . -name ".svn" -prune -o -name "target" -prune \ >> > > -o -name "*.java" -print | wc -l >> > > >> > > Count of java files with tabs is done by running "detab1.sh" (which just >> > > fixes tabs) then: >> > > svn status | grep "^M" | wc -l >> > > >> > > Count of java files with tabs or trailing whitespace is done by running >> > > "detab.sh" then svn status as above. >> > > >> > > shared/trunk: >> > > # of java files: 396 >> > > # of files with tabs: 25 >> > > # of files with tabs/trailing spaces: 51 >> > > >> > > shared/trunk12: >> > > # of java files: 390 >> > > # of files with tabs: 31 >> > > # of files with tabs/trailing spaces: 133 >> > > >> > > core/trunk: >> > > # of java files: 351 >> > > # of files with tabs: 78 >> > > # of files with tabs/trailing spaces: 216 >> > > >> > > core/trunk12: >> > > # of java files: 503 >> > > # of files with tabs: 120 >> > > # of files with tabs/trailing spaces: 385 >> > > >> > > >> > > It's interesting how many more classes there are in jsf1.2 than in >> > > jsf1.1. Some of this is due to more unit tests, but much appears to be >> > > real new classes needed to implement the extended spec. >> > > >> > > >> > > >> > > >> > > On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: >> > > > Simon, >> > > > Do you have a number? How many files do have tab characters? >> > > > I think (b - fix them) would be the better solution. But only if that >> > > > does not change every second file. >> > > > --Manfred >> > > > >> > > > >> > > > On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] >> > > > <[EMAIL PROTECTED]> wrote: >> > > > > Hi All, >> > > > > >> > > > > In the new checkstyle rules file I enabled checks for tab >> > > > > characters, as the >> > > > > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the >> > > > > checkstyle report points out a lot of files containing tabs. >> > > > > >> > > > > It's no big deal, but do we want to: >> > > > > (a) disable the checkstyle rule and ignore tabs or >> > > > > (b) fix them? >> > > > > >> > > > > Tabs are a minor nuisance when viewing the source as some tools >> > > > > render 4 >> > > > > spaces, some 8. >> > > > > >> > > > > I've written a simple shellscript that can clean this up very >> > > > > easily, and am >> > > > > happy to do so. The script also removes trailing whitespace from >> > > > > lines, of >> > > > > which we also appear to have quite a lot. >> > > > > >> > > > > But doing this will create some large commit messages and make >> > > > > comparing >> > > > > files with past versions noisier. It can also cause svn conflicts if >> > > > > people >> > > > > have modified files they have not yet committed, unless they run the >> > > > > cleanup >> > > > > script against their own working dir before doing svn update. >> > > > > >> > > > > So, option (a) or (b)? >> > > > > >> > > > > Regards, Simon >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > >> > >
