Given that both Eclipse and NetBeans have individually configurable
beautifiers, as does every other important programmers' editor, the fault,
dear Reader, lies not in our IDEs, but in ourselves, that we are possessed of
individuality and free will. [1]

Two points about version control and false deltas.

Point one, Roedy is right, only the problem is more general than just in
Editor Wars. [2]  Ergo the version control systems should handle it.  In this
sense, the fault lies not in ourselves but in CVS and Subversion.

Actually, version control systems come with the tools to handle the job.  'cvs
diff', for example, leverages diff's '-B','-b' and '-w' options.  They don't
have to report the changes in just whitespace.

Point two, it's no big deal to store whitespace-only deltas, from a storage
standpoint.  Deltas are called that because they store differential
information, so a whitespace-only delta isn't so horrid.

This begs the question of whether changes in whitespace are "false".  They may
not be of interest in a certain context, but they are changes.  Hence the diff
whitespace-ignoring options, which give the practitioner freedom to decide.
Bear in mind that no sane or responsible developer should ever check in a
whitespace-only delta - any whitespace changes will be concomitant to
substantive ones.

Nevertheless, there will be changes in whitespace if developers are given the
license to run rampant with their blanks and newlines.

The whitespace-delta issue is not one of IDE configuration but of individual
programmer style.  Even within a single IDE programmers can have different
settings.  That makes whitespace management a management issue, i.e., a
process question.

To address the question, a team must choose:

- the importance of a whitespace standard.  With daily builds and automated
testing, the significance of whitespace changes may be negligible and no
further concern justified.  Maybe we should just all get along with any
reasonable layout, and just tell every developer to reformat as they see fit
whenever it's their turn to work on a source artifact.  Make a molehill out of
the mountain.

- whether to mandate or automate source layout.  Whitespace layout is a matter
of programmer productivity - there is a kind of "impedance match" between a
layout and a programmer's mental efficiency.  Forcing developers to conform to
a single standard may reduce productivity, and may not be necessary.  Simply
run all source through a standard prettifier on the 'cvs export' to a
documentation tree  (or Subversion equivalent, natch).  You even configure an
"on commit" action, as CVS does via the commitinfo commands. [3]

- how all this fits into the larger deploy-and-test strategy.

with perhaps special consideration to comment layout.

Conclusion:

I conclude that programmers should use the editor(s) or IDE(s) of their own
choice, with the whitespace of their choice, with the version control system
of the team's choice, via scripts or other automata that format the whitespace
to the team standard on the way in to the repository, in a context of
quotidian build-and-test cycles that use Ant and similar command-line tools
and pretty-formatting on the export (yes, redundantly).  I'd much rather see
clear and thorough Javadoc comments now the programmer need not take the time
to worry whether a brace belongs on its own line.

Footnotes:

[1] misquote from Shakespeare, /Julius Caesar/, Act I, Scene II.
[2] <http://en.wikipedia.org/wiki/Editor_wars>
[3] <http://ximbiot.com/cvs/manual/cvs-1.11.22/cvs_18.html#SEC171>

If the tech lead relies on a particular IDE being used across the
development team, perhaps he/she shouldn't be a tech lead. The IDE is
just a tool to get the job done.

So use a tool like Checkstyle to enforce any particular coding standards.