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: [EMAIL PROTECTED] 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
