Ok, rather than running "detab.sh" before svn update, I suggest this
instead.
svn -q status | cut -c 8- | xargs -n 1 sed -i -e 's/\t/ /g'
It replaces tabs *only* in local files that you already have modified
versions of. The svn update therefore works normally on other files (no
conflicts).
Regards,
Simon
Andrew Robinson schrieb:
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
