I agree, we need to be careful about global reformatting; I think the
biggest issue is around tabs vs. spaces. If svn diff can ignore white
space in diffs, that would be great, and we could go ahead and convert
(carefully) all the code.
I also wouldn't even mind a filter running on svn commit that converts
all tabs to spaces, if it can be accomplished safely.
David
Mike Matrigali wrote:
I still don't think it is worth it to reformat all the code style, but
do think addressing the tab/space issue is worth it. Before we do any
reformatting I would like to clearly understand the process and any
likelyhood that the automated reformatter will introduce bugs into the
code.
My main problem is the future nightmare of backporting code. This
change will definitely increase the cost/time/likelyhood of backporting
changes. For instance most of the store code bracket style is
consistent but different than the sun style. I know eol changes caused
merges that should have been automatic to turn into hours worth of
work for me in the past.
I understand the tab/space issue and think that changing to all spaces
would help and my hope is that with appropriate flags to patch/svn we
could get merges to ignore space diffs.
Kathey Marsden wrote:
Daniel John Debrunner wrote:
-1 to defining a new format, why not just pick some existing standard.
+1 to defining some format.
I will try just a little longer and then we can just all go back to
our pain.
We go with the way the client code is described but drop the
mandatory braces around blocks so the client code should still fit.
<proposal>
Sun default style with 4 space indent (no tabs).
</proposal>
The Sun default is what is recommended at:
http://db.apache.org/source.html
Kathey
