On Thu, Mar 16, 2006 at 10:09:12AM -0800, Stefano Mazzocchi wrote:
> Richard Liang wrote:
> >Dears,
> >
> >If you select "Spaces only" as Eclipse "tab policy" and you format the
> >Harmony source code in Eclipse, when you creating patch for the source
> >code, Subclipse may regard the source code as total different with the
> >source in SVN. Then other developers cannot know what you have changed
> >to the source code. So are there any way to avoid this confusion? Thanks
> >a lot.
>
> If you figured that out, I would be the happiest person alive: I *HATE*
> tabs with a passion and that is the only part of the eclipse that drives
> me completely insane.
Silly eclipse users...
...the generic problem here is that "diff" is not a very good tool for
representing changes made to large java codebases. What we need is a tool
that represents the change as something like this:
From: john@apache
To: harmony-commits
Subject: svn revision 12345 - foo/bar foo/baz
Reformatted code (format http://.../harmony.style):
foo/bar/x.java
foo/bar/y.java
Refactorings:
move-static: foo/bar/x.java -> foo/bar/y.java:
public static void doStuff(String x)
public static void doStuff(String x, String y)
I've pretty much figured out how to do this in theory (refactorings are
syntax tree transformations for which you can write a pattern matching
algorithm (parse tree pattern, not text pattern)), its just something that
takes a man-year or two to implement...
...so in the meantime...
...write these kinds of message manually. When you do a code reformat, say
so in the commit message, don't change anything else. When you do some kind
of refactoring, describe the refactoring in the commmit message. This helps
other people understand what you did (figuring out the refactorings from the
diff in the commit message is rather hard).
When you're submitting a patch, submit two patches. One that is just the
code reformat, and the other that is the "real" patch applied to the
reformatted code. The developer applying your patch can then first apply
the reformat patch, commit, and then commit the "real" patch. All he has
to do for the reformat patch is verify that it is just a reformat, and then
he can actually understand the real patch too.
Make sense?
The final thing to do is for projects to lay down a very rigid coding
standards law (I would like to volunteer tim to put his eclipse settings up
on the wiki, I guess that's currently sort-of our de-facto coding standards
rules) and apply it to all the source in one fell swoop. Then you don't
have to submit those reformatting patches.
cheers!
LSD
|