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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
