Hi all, yesterday i was checking in a lot of new SIMD stuff into the devel_0_37, but then i took back the changes because i realized that my editor changed much of the whitespaces in the code which results in lengthy diffs and lots of work for future merging (hi Günther!!).
Thus, my question is: Is there a common practice which kind of whitespace treatment should be used for newly created or modified PD source code? I personally use spaces rather than tabs and 4 space indents, which seems quite widespread. The other thing is that i wonder whether the configure file should be in the cvs at all, since it's created from configure.in .
all the best, Thomas
You might try the cvs flags for ignoring whitespace.
Best regards,
Chris.
On Thu, Oct 07, 2004 at 10:20:27AM +0200, Thomas Grill wrote:
Hi all, yesterday i was checking in a lot of new SIMD stuff into the devel_0_37, but then i took back the changes because i realized that my editor changed much of the whitespaces in the code which results in lengthy diffs and lots of work for future merging (hi G?nther!!).
Thus, my question is: Is there a common practice which kind of whitespace treatment should be used for newly created or modified PD source code? I personally use spaces rather than tabs and 4 space indents, which seems quite widespread. The other thing is that i wonder whether the configure file should be in the cvs at all, since it's created from configure.in .
all the best, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
------------------- chris@mccormick.cx http://mccormick.cx
On Thu, Oct 07, 2004 at 04:41:11PM +0800, Chris McCormick wrote:
You might try the cvs flags for ignoring whitespace.
Best regards,
Chris.
On Thu, Oct 07, 2004 at 10:20:27AM +0200, Thomas Grill wrote:
Hi all, yesterday i was checking in a lot of new SIMD stuff into the devel_0_37, but then i took back the changes because i realized that my editor changed much of the whitespaces in the code which results in lengthy diffs and lots of work for future merging (hi G?nther!!).
Thus, my question is: Is there a common practice which kind of whitespace treatment should be used for newly created or modified PD source code? I personally use spaces rather than tabs and 4 space indents, which seems quite widespread. The other thing is that i wonder whether the configure file should be in the cvs at all, since it's created from configure.in .
all the best, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
chris@mccormick.cx http://mccormick.cx
------------------- chris@mccormick.cx http://mccormick.cx
Hi Thomas,
As of 0.38 I'm using all spaces... I was hoping this policy would _reduce_ whitespace trouble. Heretofore the files have sometimes had spaces where tabs could be used, and sometimes used tabs.
cheers Miller
On Thu, Oct 07, 2004 at 10:20:27AM +0200, Thomas Grill wrote:
Hi all, yesterday i was checking in a lot of new SIMD stuff into the devel_0_37, but then i took back the changes because i realized that my editor changed much of the whitespaces in the code which results in lengthy diffs and lots of work for future merging (hi Günther!!).
Thus, my question is: Is there a common practice which kind of whitespace treatment should be used for newly created or modified PD source code? I personally use spaces rather than tabs and 4 space indents, which seems quite widespread. The other thing is that i wonder whether the configure file should be in the cvs at all, since it's created from configure.in .
all the best, Thomas
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Thu, 7 Oct 2004, Miller Puckette wrote:
As of 0.38 I'm using all spaces... I was hoping this policy would _reduce_ whitespace trouble. Heretofore the files have sometimes had spaces where tabs could be used, and sometimes used tabs.
Alright. If you really have changed the whitespace in all files, it will be pretty impossible to merge that into devel_0_37 ... unless ignore-leading-whitespace is in use ... and from that point the original conversion to whitespace has become pointless.
____________________________________________________________________ Matsjö Buschahr @ Medien.kunstLabor.AT, Graz, Österreich http://convention.puredata.info/ http://artengine.ca/matju
Well, no, not pointless, because diffs should still work, as long as they ignore white space. The trouble I was having was that patches to the main branch were making wierd indentation (I think because different people use different tabspace indentations). So I think a spaces-only main branch is easier to "patch" to.
I'm not really sure this is the best way...
cheers Miller
On Fri, Oct 08, 2004 at 07:29:06AM -0400, Matju wrote:
On Thu, 7 Oct 2004, Miller Puckette wrote:
As of 0.38 I'm using all spaces... I was hoping this policy would _reduce_ whitespace trouble. Heretofore the files have sometimes had spaces where tabs could be used, and sometimes used tabs.
Alright. If you really have changed the whitespace in all files, it will be pretty impossible to merge that into devel_0_37 ... unless ignore-leading-whitespace is in use ... and from that point the original conversion to whitespace has become pointless.
Matsjö Buschahr @ Medien.kunstLabor.AT, Graz, Österreich http://convention.puredata.info/ http://artengine.ca/matju
On Fri, 8 Oct 2004, Miller Puckette wrote:
Well, no, not pointless, because diffs should still work, as long as they ignore white space. The trouble I was having was that patches to the main branch were making wierd indentation (I think because different people use different tabspace indentations). So I think a spaces-only main branch is easier to "patch" to.
If the diff command directly supports that feature of ignoring leading whitespace then there's no point in making the change; but if instead you need special preprocessing scripts that are only integrated into CVS and not the regular diff then you are right.
____________________________________________________________________ Matsjö Buschahr @ Ruby Konferenz, Muenchen http://artengine.ca/matju