You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by David Crossley <cr...@indexgeo.com.au> on 2003/11/10 05:52:28 UTC
whitespace cleanup and efficiency drive
It might sound pedantic, but it is about efficiency.
I have wasted a lot of time during my committer life with
confusing patches that contain mainly whitespace changes.
Not to criticise the patcher or their tools, but today
was a classic. With some manual tweaks to whitespace,
i managed to bring one diff down from 450 lines to 120 lines.
What caused this grief? Well the files in cvs had inconsistent
whitespace, most indentations were 4-space, some were 3-space,
some line of text had two spaces between words rather than one,
and other spurious issues. Now when the developer edited that
file, their text editor must have tried to fix the whitespace,
but in many cases made it worse.
Therefore the diff was full of clutter. If i had committed
it then no-one would have been able to review the changes.
It would look like almost every line had changed. Also the cvs
files would have been in a worse state and then perpetuate it.
I suppose that it is a dream, but does anybody know about a
tool that would automatically apply say 4-space indentation
and whitespace clean up? We could apply that to our whole
cvs say once per month.
--David
Re: whitespace cleanup and efficiency drive
Posted by Tony Collen <co...@umn.edu>.
David Crossley wrote:
> tony
> src/blocks/scratchpad/samples/othello/osml/core/layout.xsl
> ... recent one, still not fixed.
Thanks for the heads up. I'll check it out tomorrow when I'm at work.
Too many files to keep track of at once. :P
>
> I will keep monitoring CVS to see if there are any others.
>
> --David
>
>
>
Regards,
Tony
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Joerg Heinicke wrote:
>
> Not a witch-hunt, but name the people. They must know it,
> that something is broken. I for example use Eclipse and WinCVS.
> I can at least imagine that a problematic constellation can be
> using cvs from cygwin, so you have a mixture of Linux/Windows tools.
Yes, there are many ways that line-endings problems can creep in.
One way is committers on UNIX-like systems accepting a patch from
Bugzilla and forgetting to do a dos2unix on the files. That can also
give us nasty mixed line-endings.
The other ways are via improperly configured Windows tools.
Now to the people that may have problem systems. We want to help
each other here, so don't feel bad. If we can identify some common
issues then we can add them to the FAQs.
This detective work was done using 'cvs log' for some of the problem
files and by watching commits since i started the cleaning. Only looked
at recent commits, ignored the past. This is not to say these are the
only people. For each person i added one example of a problem.
ghoward
src/confpatch/* ... some had mixed line-endings.
unico
src/blocks/slide/samples/flow.js
These last three recent cases may be due to the
"accepting a foreign file" problem:
joerg
legal/LICENCE.xindice
tools/ide/eclipse/project
stephan
tools/jalopy/conf/convention.xml
tony
src/blocks/scratchpad/samples/othello/osml/core/layout.xsl
... recent one, still not fixed.
I will keep monitoring CVS to see if there are any others.
--David
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Joerg Heinicke wrote:
> David Crossley wrote:
>
> > Okay, i now have the cocoon-2.2 CVS completely clean of
> > any dos2unix problems.
> >
> > Now we are not going on a witch-hunt or anything, but ...
>
> Not a witch-hunt, but name the people. They must know it, that something
> is broken. I for example use Eclipse and WinCVS. I can at least imagine
> that a problematic constellation can be using cvs from cygwin, so you
> have a mixture of Linux/Windows tools.
I am not sure who they are yet. After a while i will run the tests
again and we will see. Gradually we will alleviate the problems.
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.12.2003 06:24, David Crossley wrote:
> Okay, i now have the cocoon-2.2 CVS completely clean of
> any dos2unix problems.
>
> Now we are not going on a witch-hunt or anything, but ...
Not a witch-hunt, but name the people. They must know it, that something
is broken. I for example use Eclipse and WinCVS. I can at least imagine
that a problematic constellation can be using cvs from cygwin, so you
have a mixture of Linux/Windows tools.
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
David Crossley dijo:
> Antonio Gallardo wrote:
>> David Crossley dijo:
>> > Perhaps the Ant project has a corrupted CVS like our was.
>> > They might have dos line-endings in their ant.bat etc.
>>
>> I thought .bat files must have line ending as DOS: 0x0D 0x0A
>> And Linux files must have just 0x0A
>>
>> Is this correct?
>
> No, not correct. On a UNIX system all files must have UNIX line-endings.
> The machine cvs.apache.org is UNIX.
OK. In short, I need to change all the bat files to UNIX line ending.
Thanks for the explanation. I will do it. :-D
Best Regards,
Antonio Gallardo
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Antonio Gallardo wrote:
> David Crossley dijo:
> > Perhaps the Ant project has a corrupted CVS like our was.
> > They might have dos line-endings in their ant.bat etc.
>
> I thought .bat files must have line ending as DOS: 0x0D 0x0A
> And Linux files must have just 0x0A
>
> Is this correct?
No, not correct. On a UNIX system all files must have UNIX line-endings.
The machine cvs.apache.org is UNIX.
When someone on a windows machine does a cvs checkout, then their
cvs client would fix all line endings for them.
When someone downloads a distribution, e.g. cocoon-2.1.3.zip, then
they should find that all line-endings have been already converted
for them by the build script that made the distribution. If they
instead wrongly downloaded the cocoon-2.1.3.tar.gz then they would
have UNIX line-endings. If the build file does not handle the crlf
thing, then the release manager would need to build the .zip on
Windows and the .tar.gz on UNIX.
--David
> The files in the ant distribution follow this. I think the files we had
> before does not follow this.
>
> But if our standard said all files need to be UNIX line ending style and
> we need UNIX line ending syle in DOS .bat files I will change them to UNIX
> line ending.
>
> Please answer, because I am confused about the original Vadim request.
>
webdav block cleanup (Was: whitespace cleanup and efficiency drive)
Posted by David Crossley <cr...@indexgeo.com.au>.
If anyone is working in the webdav block, then would they
please commit any outstanding stuff. Sometime mid next week
i would like to fix all the dos2unix problems in there.
If you want me to hold off for a while, then please say so.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25381
--David
On Wed, 2003-12-10 at 16:24, David Crossley wrote:
> Okay, i now have the cocoon-2.2 CVS completely clean of
> any dos2unix problems.
>
> Now we are not going on a witch-hunt or anything, but ...
>
> I have perceptions that there are some committers who use
> CVS clients that don't handle the linefeed conversion properly.
> It would be good to find those cases and get them fixed.
>
> Occasionally i will run the "find|grep" stuff and report back.
>
>
> As for the Cocoon-2.1 CVS, there are still many issues.
> Gradually i have been fixing it, and notice Vadim doing some.
>
> There are two big areas that need conversion and i want to
> do those as a batch:
> src/blocks/webdav/samples/
> scratchpad/samples/sitemap-viewer/
>
> How should i approach this? With the sitemap-viewer i can
> probably just go ahead, but the webdav block potentially
> has many people working on it.
>
> Anyway, i am going to experiment with a Bugzilla task
> to manage the line-endings issue.
>
> --David
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Okay, i now have the cocoon-2.2 CVS completely clean of
any dos2unix problems.
Now we are not going on a witch-hunt or anything, but ...
I have perceptions that there are some committers who use
CVS clients that don't handle the linefeed conversion properly.
It would be good to find those cases and get them fixed.
Occasionally i will run the "find|grep" stuff and report back.
As for the Cocoon-2.1 CVS, there are still many issues.
Gradually i have been fixing it, and notice Vadim doing some.
There are two big areas that need conversion and i want to
do those as a batch:
src/blocks/webdav/samples/
scratchpad/samples/sitemap-viewer/
How should i approach this? With the sitemap-viewer i can
probably just go ahead, but the webdav block potentially
has many people working on it.
Anyway, i am going to experiment with a Bugzilla task
to manage the line-endings issue.
--David
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Vadim Gritsenko wrote:
> David Crossley wrote:
> >Joerg Heinicke wrote:
> >
> >>The result of this thread: let's care only about white spaces.
> >
> >So now we need a policy. Here is my proposal:
> >
> >For all text files
> >- Replace all tabs with spaces.
> >- No trailing whitespace.
> >- No M$-DOS line endings.
> >- Newline at end-of-file.
> >- Single whitespace between words.
> >
> >For cvs/**.java
> >- Use 4-space indentation.
> >
> >For cvs/**.xml|xmap|xconf etc.
> >- Use 2-space indentation.
> >- No whitespace at start-of-file.
>
> All of the above is either common sense or even more (like the last one:
> XML won't be XML if starts with whitespace (see spec)), and should be
> enforced as soon as you find an issue.
>
> >- No whitespace at end-of-file.
>
> Newline should be ok, right?
Okay, i added a new document at the top-level site to note this policy.
http://cocoon.apache.org/community/committer.html
--David
Re: whitespace cleanup and efficiency drive
Posted by Vadim Gritsenko <va...@verizon.net>.
David Crossley wrote:
>Joerg Heinicke wrote:
>
>
>>The result of this thread: let's care only about white spaces.
>>
>>
>
>So now we need a policy. Here is my proposal:
>
>For all text files
>- Replace all tabs with spaces.
>- No trailing whitespace.
>- No M$-DOS line endings.
>- Newline at end-of-file.
>- Single whitespace between words.
>
>For cvs/**.java
>- Use 4-space indentation.
>
>For cvs/**.xml|xmap|xconf etc.
>- Use 2-space indentation.
>- No whitespace at start-of-file.
>
>
All of the above is either common sense or even more (like the last one:
XML won't be XML if starts with whitespace (see spec)), and should be
enforced as soon as you find an issue.
>- No whitespace at end-of-file.
>
Newline should be ok, right?
Vadim
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Joerg Heinicke wrote:
> The result of this thread: let's care only about white spaces.
So now we need a policy. Here is my proposal:
For all text files
- Replace all tabs with spaces.
- No trailing whitespace.
- No M$-DOS line endings.
- Newline at end-of-file.
- Single whitespace between words.
For cvs/**.java
- Use 4-space indentation.
For cvs/**.xml|xmap|xconf etc.
- Use 2-space indentation.
- No whitespace at start-of-file.
- No whitespace at end-of-file.
Re: [OT Re: whitespace cleanup and efficiency drive
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Stefano Mazzocchi dijo:
> I've started to evaluate IDEA as well because eclipse on mach-o is
> simply not usable if you don't have several GBs of RAM (and I don't)
lol. We are using Eclipse and in fact I need to upgrade our 3 machines to
512, 768 and 1024 of RAM respectively. :-D
It looks like eclipse has a "contract" with RAM producents. :-D
Best Regards,
Antonio Gallardo
Re: [OT Re: whitespace cleanup and efficiency drive
Posted by Torsten Curdt <tc...@vafer.org>.
>> Hm... just wondering if they might give away a general
>> ASF licence (that is maybe restricted on editing classes
>> only in org.apache packages)
>>
>> ...may I ask as Apache "representative"?
>
>
> no, but you can ask the ASF board as Apache committer. ;-)
well, will do this then :)
--
Torsten
[OT] IDEA (Was: whitespace cleanup and efficiency drive)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mercredi, 12 nov 2003, à 14:57 Europe/Zurich, Stefano Mazzocchi a
écrit :
> ...I'll keep you people posted on this since many switchers find
> themselves with one thing missing: a decent java IDE...
>
FWIW, I've been using IDEA on macosx since the beginning of this year,
and I like it a lot (actually they could send me a bag of chocolate,
I've said this several times already ;-)
I'm not an IDE guy though, so I don't know about "exotic" features, but
for editing, navigating code, debugging and launching ant tasks it is
perfect for me, and you can feel that its designers are code guys - it
is packed with nice touches which make my (programming) life easier!
-Bertrand
Re: [OT Re: whitespace cleanup and efficiency drive
Posted by Stefano Mazzocchi <st...@apache.org>.
On 12 Nov 2003, at 12:05, Torsten Curdt wrote:
>>> IDEA does it pretty good: Removes trailing spaces when saving a
>>> file, replaces existing tabs with spaces on save, when using the key
>>> TAB it adds spaces to the file. But unfortunately IDEA is not for
>>> free.
>> Ah, others keep mentioning IDEA too.
>
> Hm... just wondering if they might give away a general
> ASF licence (that is maybe restricted on editing classes
> only in org.apache packages)
>
> ...may I ask as Apache "representative"?
no, but you can ask the ASF board as Apache committer. ;-)
I've started to evaluate IDEA as well because eclipse on mach-o is
simply not usable if you don't have several GBs of RAM (and I don't)
So far, it's beating the crap out of eclipse in terms of performance on
macosx... but I haven't really *load it* as much as I did with eclipse.
I'll keep you people posted on this since many switchers find
themselves with one thing missing: a decent java IDE (panther's Xcode
is not so bad... but it's simply too mac-oriented... it's great for
objective-c.. but misses way too many features that eclipse and IDEA
have)
> --
Stefano.
[OT Re: whitespace cleanup and efficiency drive
Posted by Torsten Curdt <tc...@vafer.org>.
>>IDEA does it pretty good: Removes trailing
>>spaces when saving a file, replaces existing tabs with spaces on save,
>>when using the key TAB it adds spaces to the file. But unfortunately
>>IDEA is not for free.
>
>
> Ah, others keep mentioning IDEA too.
Hm... just wondering if they might give away a general
ASF licence (that is maybe restricted on editing classes
only in org.apache packages)
...may I ask as Apache "representative"?
--
Torsten
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Joerg Heinicke wrote:
> The result of this thread: let's care only about white spaces.
>
> It's my opinion too. But the editor should do this automatically, not by
> running a task by hand.
Agreed. I am adding it to my requirements list, in the search for
a new editor.
> IDEA does it pretty good: Removes trailing
> spaces when saving a file, replaces existing tabs with spaces on save,
> when using the key TAB it adds spaces to the file. But unfortunately
> IDEA is not for free.
Ah, others keep mentioning IDEA too.
> The editors I use at the moment are Eclipse and jEdit. Both can insert
> spaces instead of TAB when using the key. But both do not handle the
> other two things. And even worse for XML with Eclipse and SunBow: it
> does not even handle the TAB => spaces issue.
>
> Even if this leads not to additional results my conclusion:
> Having the right tools we would not have such problems.
That is right. However we cannot expect everyone to have them.
So, from time-to-time perhaps one of us can do a
"whitespace cleanup" of our cvs.
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jh...@virbus.de>.
The result of this thread: let's care only about white spaces.
It's my opinion too. But the editor should do this automatically, not by
running a task by hand. IDEA does it pretty good: Removes trailing
spaces when saving a file, replaces existing tabs with spaces on save,
when using the key TAB it adds spaces to the file. But unfortunately
IDEA is not for free.
The editors I use at the moment are Eclipse and jEdit. Both can insert
spaces instead of TAB when using the key. But both do not handle the
other two things. And even worse for XML with Eclipse and SunBow: it
does not even handle the TAB => spaces issue.
Even if this leads not to additional results my conclusion:
Having the right tools we would not have such problems.
Joerg
On 10.11.2003 05:52, David Crossley wrote:
> It might sound pedantic, but it is about efficiency.
>
> I have wasted a lot of time during my committer life with
> confusing patches that contain mainly whitespace changes.
> Not to criticise the patcher or their tools, but today
> was a classic. With some manual tweaks to whitespace,
> i managed to bring one diff down from 450 lines to 120 lines.
>
> What caused this grief? Well the files in cvs had inconsistent
> whitespace, most indentations were 4-space, some were 3-space,
> some line of text had two spaces between words rather than one,
> and other spurious issues. Now when the developer edited that
> file, their text editor must have tried to fix the whitespace,
> but in many cases made it worse.
>
> Therefore the diff was full of clutter. If i had committed
> it then no-one would have been able to review the changes.
> It would look like almost every line had changed. Also the cvs
> files would have been in a worse state and then perpetuate it.
>
> I suppose that it is a dream, but does anybody know about a
> tool that would automatically apply say 4-space indentation
> and whitespace clean up? We could apply that to our whole
> cvs say once per month.
>
> --David
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Bertrand Delacretaz wrote:
> David Crossley a écrit :
>
> > ...
> > Well this is all that this discussion really set out to achieve:
> > consistent 4-space indentation, remove all tabs, get rid of other
> > spurious whitespace. So, yes, let us stop at that.
>
> +1, keep it simple!
>
> IIUC the whole point is to have easy to work with CVS diffs,
YDUC ... You Do Understand Correctly.
> the rest
> is largely personal taste, mostly impossible to agree on.
>
> "diff -b" also helps ignore "reasonable" whitespace differences.
I learn something every minute.
--David
Re: whitespace cleanup and efficiency drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 10 nov 2003, à 16:56 Europe/Zurich, David Crossley a écrit :
> ...
> Well this is all that this discussion really set out to achieve:
> consistent 4-space indentation, remove all tabs, get rid of other
> spurious whitespace. So, yes, let us stop at that.
+1, keep it simple!
IIUC the whole point is to have easy to work with CVS diffs, the rest
is largely personal taste, mostly impossible to agree on.
"diff -b" also helps ignore "reasonable" whitespace differences.
-Bertrand
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
>
> Stop!
>
> history shows pretty evidently that you can't reach consensus on style,
> unless your compiler is style dependant (which is why Python code all
> looks the same!).
>
> tab is bad. everytime you see tabs you should change them into 4
> whitespaces. this is the general practice for java code in the ASF.
>
> this is the *ONLY* wide practice.
>
> let's not start the debate.
Well this is all that this discussion really set out to achieve:
consistent 4-space indentation, remove all tabs, get rid of other
spurious whitespace. So, yes, let us stop at that.
--David
Re: whitespace cleanup and efficiency drive
Posted by Stefano Mazzocchi <st...@apache.org>.
On 10 Nov 2003, at 14:06, David Crossley wrote:
> Vadim Gritsenko wrote:
>>
>> If we agree on style, I can run IDEA on whole source tree
>
> Yes, if we can "just" define the style then any of our tools
> should be able to apply it.
>
> Perhaps we could gradually develop our "style". For example
> start with only "indentation and whitespace", get that sorted
> for both java and xml, then address another issue, and so on.
Stop!
history shows pretty evidently that you can't reach consensus on style,
unless your compiler is style dependant (which is why Python code all
looks the same!).
tab is bad. everytime you see tabs you should change them into 4
whitespaces. this is the general practice for java code in the ASF.
this is the *ONLY* wide practice.
let's not start the debate.
--
Stefano.
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Andrew Savory wrote:
> David Crossley wrote:
>
> > Perhaps we could gradually develop our "style". For example
> > start with only "indentation and whitespace", get that sorted
> > for both java and xml, then address another issue, and so on.
>
> I thought our style was already defined, as "like Sun"?
Yes, but this is about actually applying it.
Does anyone know about any coding guidelines for XML?
--David
Re: whitespace cleanup and efficiency drive
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Andrew Savory wrote:
> On Mon, 11 Nov 2003, David Crossley wrote:
>
>>Perhaps we could gradually develop our "style". For example
>>start with only "indentation and whitespace", get that sorted
>>for both java and xml, then address another issue, and so on.
>
> I thought our style was already defined, as "like Sun"?
Oh, my, again with style issues :-/
http://jakarta.apache.org/poi/resolutions/res001.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: whitespace cleanup and efficiency drive
Posted by Andrew Savory <an...@luminas.co.uk>.
On Mon, 11 Nov 2003, David Crossley wrote:
> Perhaps we could gradually develop our "style". For example
> start with only "indentation and whitespace", get that sorted
> for both java and xml, then address another issue, and so on.
I thought our style was already defined, as "like Sun"?
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
Orixo alliance: http://www.orixo.com/ Web: www.luminas.co.uk
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Vadim Gritsenko wrote:
>
> If we agree on style, I can run IDEA on whole source tree
Yes, if we can "just" define the style then any of our tools
should be able to apply it.
Perhaps we could gradually develop our "style". For example
start with only "indentation and whitespace", get that sorted
for both java and xml, then address another issue, and so on.
--David
RE: whitespace cleanup and efficiency drive
Posted by Reinhard Poetz <re...@apache.org>.
From: Vadim Gritsenko
> David Crossley wrote:
>
> >I suppose that it is a dream, but does anybody know about a
> tool that
> >would automatically apply say 4-space indentation and
> whitespace clean
> >up? We could apply that to our whole cvs say once per month.
> >
> >
>
> If we agree on style, I can run IDEA on whole source tree
now comes the funny part ;-)
--
Reinhard
Re: whitespace cleanup and efficiency drive
Posted by Vadim Gritsenko <va...@verizon.net>.
David Crossley wrote:
>I suppose that it is a dream, but does anybody know about a
>tool that would automatically apply say 4-space indentation
>and whitespace clean up? We could apply that to our whole
>cvs say once per month.
>
>
If we agree on style, I can run IDEA on whole source tree
Vadim
Re: whitespace cleanup and efficiency drive
Posted by Ugo Cei <u....@cbim.it>.
David Crossley wrote:
> Looks interesting and worth a try. Now we need one for xml too.
jEdit with the XSL-T plugin.
Ugo
--
Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
Re: whitespace cleanup and efficiency drive
Posted by Giacomo Pati <gi...@apache.org>.
David Crossley wrote:
> Giacomo Pati wrote:
>
>>David Crossley wrote:
>
> <snip/>
>
>>>That would be nice for us. Unfortunately, we probably have to take
>>>whatever comes and fix it with clever tools before commit.
>>
>>Be carful when doing precommit reformatting on the cvs server side
>>(which is doable with CVS). This might give you conflict as soon as you
>>commit your next changes to the same file or it requires you to
>>immediately update your tree after such committs.
>
>
> Wait, i did not mean that ... re-wind ...
:-)
> We committers need clever local tools that apply consistent
> style prior to making our commits.
than Jalopy could be used for it (as Ant task or IDE plugin)
> Thanks for picking that up.
It was an experiment we made which failed badly because of those issues
I've mentioned.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Giacomo Pati wrote:
> David Crossley wrote:
<snip/>
> > That would be nice for us. Unfortunately, we probably have to take
> > whatever comes and fix it with clever tools before commit.
>
> Be carful when doing precommit reformatting on the cvs server side
> (which is doable with CVS). This might give you conflict as soon as you
> commit your next changes to the same file or it requires you to
> immediately update your tree after such committs.
Wait, i did not mean that ... re-wind ...
We committers need clever local tools that apply consistent
style prior to making our commits.
Thanks for picking that up.
--David
Re: whitespace cleanup and efficiency drive
Posted by Giacomo Pati <gi...@apache.org>.
David Crossley wrote:
> Tony Collen wrote:
>
>>David Crossley wrote:
>>
>>><snip/>
>>>I suppose that it is a dream, but does anybody know about a
>>>tool that would automatically apply say 4-space indentation
>>>and whitespace clean up? We could apply that to our whole
>>>cvs say once per month.
>>
>>Jalopy?
>>
>>http://jalopy.sourceforge.net/
>>
>>Never used it, just Google'd it.
>
>
> Looks interesting and worth a try. Now we need one for xml too.
There is also an Eclipse plugin. We use it since over a year (probably).
>>I'm +1 for making our source easier to read. Maybe we should also
>>instate a policy that incoming patches from non-committers should either
>>be submitted properly formatted, or we won't take it.
>
>
> That would be nice for us. Unfortunately, we probably have to take
> whatever comes and fix it with clever tools before commit.
Be carful when doing precommit reformatting on the cvs server side
(which is doable with CVS). This might give you conflict as soon as you
commit your next changes to the same file or it requires you to
immediately update your tree after such committs.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Tony Collen wrote:
> David Crossley wrote:
> > <snip/>
> > I suppose that it is a dream, but does anybody know about a
> > tool that would automatically apply say 4-space indentation
> > and whitespace clean up? We could apply that to our whole
> > cvs say once per month.
>
> Jalopy?
>
> http://jalopy.sourceforge.net/
>
> Never used it, just Google'd it.
Looks interesting and worth a try. Now we need one for xml too.
> I'm +1 for making our source easier to read. Maybe we should also
> instate a policy that incoming patches from non-committers should either
> be submitted properly formatted, or we won't take it.
That would be nice for us. Unfortunately, we probably have to take
whatever comes and fix it with clever tools before commit.
--David
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@indexgeo.com.au>.
Tony Collen wrote:
>
> Perhaps we need a Guide to Not Letting Your Editor Mess Up The Code(tm).
This is the crux of the issue. We should not care how the
diffs or files come to us. Any old mess will suffice. As long
as we committers have tools to handle it. We apply the diff,
run the tool to re-apply the indentation and perhaps other style,
then review is easier and commit is cleaner.
Sure, we still need to encourage good style. We need to define
that style first then configure our tools to apply it.
--David
Re: whitespace cleanup and efficiency drive
Posted by Per-Olof Noren <pe...@alma.nu>.
On Mon, 2003-11-10 at 06:16, Tony Collen wrote:
<snip/>
> Jalopy?
>
> http://jalopy.sourceforge.net/
We are using jalopy to format bean classes generated from OJB mapping
files. It works like a charm.
+1
(2 cents worth)
Regards,
Per-Olof Norén
Re: whitespace cleanup and efficiency drive
Posted by Tony Collen <co...@umn.edu>.
David Crossley wrote:
> It might sound pedantic, but it is about efficiency.
>
> I have wasted a lot of time during my committer life with
> confusing patches that contain mainly whitespace changes.
> Not to criticise the patcher or their tools, but today
> was a classic. With some manual tweaks to whitespace,
> i managed to bring one diff down from 450 lines to 120 lines.
>
> What caused this grief? Well the files in cvs had inconsistent
> whitespace, most indentations were 4-space, some were 3-space,
> some line of text had two spaces between words rather than one,
> and other spurious issues. Now when the developer edited that
> file, their text editor must have tried to fix the whitespace,
> but in many cases made it worse.
Perhaps we need a Guide to Not Letting Your Editor Mess Up The Code(tm).
I know things like Textpad can really goof up source automatically.
*guilty nervous cough*
> Therefore the diff was full of clutter. If i had committed
> it then no-one would have been able to review the changes.
> It would look like almost every line had changed. Also the cvs
> files would have been in a worse state and then perpetuate it.
I had this problem briefly where my editor was removing extra whitespace
from the end of lines automatically on save, and then the diffs were
showing up with changed lines where it wasn't apparent there was a
change at all.
>
> I suppose that it is a dream, but does anybody know about a
> tool that would automatically apply say 4-space indentation
> and whitespace clean up? We could apply that to our whole
> cvs say once per month.
Jalopy?
http://jalopy.sourceforge.net/
Never used it, just Google'd it.
I'm +1 for making our source easier to read. Maybe we should also
instate a policy that incoming patches from non-committers should either
be submitted properly formatted, or we won't take it.
>
> --David
>
>
Regards,
Tony
RE: whitespace cleanup and efficiency drive
Posted by Reinhard Poetz <re...@apache.org>.
From: David Crossley
> It might sound pedantic, but it is about efficiency.
>
> I have wasted a lot of time during my committer life with
> confusing patches that contain mainly whitespace changes. Not
> to criticise the patcher or their tools, but today was a
> classic. With some manual tweaks to whitespace, i managed to
> bring one diff down from 450 lines to 120 lines.
>
> What caused this grief? Well the files in cvs had
> inconsistent whitespace, most indentations were 4-space, some
> were 3-space, some line of text had two spaces between words
> rather than one, and other spurious issues. Now when the
> developer edited that file, their text editor must have tried
> to fix the whitespace, but in many cases made it worse.
>
> Therefore the diff was full of clutter. If i had committed
> it then no-one would have been able to review the changes.
> It would look like almost every line had changed. Also the
> cvs files would have been in a worse state and then perpetuate it.
>
> I suppose that it is a dream, but does anybody know about a
> tool that would automatically apply say 4-space indentation
> and whitespace clean up? We could apply that to our whole cvs
> say once per month.
Maybe http://checkstyle.sourceforge.net/ could help here. The big
advantage: it has an Eclipse plug-in.
Cheers,
Reinhard