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...@apache.org> on 2004/02/17 06:17:22 UTC
Re: whitespace cleanup and efficiency drive
[Changing the subject and hopefully appending this good stuff
to the whitespace thread.
Was: Re: cvs commit: cocoon-2.1/legal LICENSE.ant]
Joerg Heinicke wrote:
> David Crossley wrote:
> >
> > Every time a UNIX-based committer receives files from somewhere
> > else (for example Buzgilla Patch or another project) then they
> > need to ensure that they do not have a Windows problem. Do a
> > 'dos2unix' on the files to fix them.
> >
> > For a Windows-based committer, they may need to do the opposite
> > (i do not know) and they definitely need to ensure that they
> > have a proper CVS client that converts the line endings to the
> > UNIX-style on commit.
>
> From the latest commit messages I found another reason for a line
> ending issue: many text files were committed as binary files and are so
> an almost guaranteed source of line endings problems. When committed
> from Unix David's line endings test is passed, but you can't view the
> files in Windows in little editors like notepad. When committed from
> Windows David's test fails, he fixes it and you can again not view the
> files in Windows. The problem is that binary files remain untouched when
> committed to CVS and so the line endings that the CVS client should
> handle in theory.
>
> What's the stuff in CVS? It's called keyword substitution and for
> binaries the value is set to -kb, for ASCII you have different
> possibilities (keyword replacement, keyword expansion, keywords
> untouched and some more), I simple chose the Eclipse default -kkv
> (expansion). I don't know how to do this from command line, but I guess
> simply by committing with the additional -kkv.
The -k option is only for 'add' and 'update' etc.
The default with the command-line client is to do ASCII and you
need to explicitly do 'cvs add -kb' for images, and jar files, etc.
> I chose Eclipse (Team >
> Change ASCII/Binary Property) and it was a bit of manual work (I felt
> like in the game Diablo: click & fight, but here where no monsters, only
> binary files ;). When adding 'CVS' to the label decorations (which I
> have done to see easily which files are locally modified) you also see
> whether the files are ASCII or binary - you only have to open and close
> all directories. It would be good to get this work done automatically,
> or at least the list of all binary files.
I had started a Perl script for another job and changed it to
deal with this. It operates on the output from 'cvs log'.
See the script on apache.org in my home directory
~crossley/bin/binarytext.pl
I have run it on the "woody" block and cannot see any problems.
Someone with more bandwidth could run it on the whole cocoon CVS.
> What can be done in future: Configure your CVS client correctly. From
> the blocks and their initial committers you see problem candidates:
>
> woody > htmlarea Ugo
> taglib
> portal, portal-fw Carsten
> ojb Antonio
> linotype Stefano
> eventcache Geoff
>
> We must not add files with (for the server unknown) file endings add
> "automatically", you must add them ASCII style (I know WinCVS has this
> explicitely, but I don't know about Eclipse). Another option is of
> course to set the file styles server side, but I don't know if we can do
> it for every file ending (imagine the files in legal), but at least for
> CSS, JS, XMAP, XROLES, XCONF, etc.
I have a big list of what should be a text file extension in the
binarytext.pl script. Perhaps we need to change our license files
to have a .txt filename extension.
> If David has observed the commits more deeper I guess many files were
> known to him for dos2unix commits. When paying attention to the
> ASCII/binary issue we will exempt him from this work to a certain extent
> and he can invest his time on real Cocoon or Forrest features :)
>
> Joerg
Thanks Joerg, for your important discovery and follow-up work.
Yes i would rather work on "real" features, but i think that it
is very important to have an efficient CVS, so i do not mind doing
this type of work too.
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.02.2004 06:17, David Crossley wrote:
> I have a big list of what should be a text file extension in the
> binarytext.pl script. Perhaps we need to change our license files
> to have a .txt filename extension.
What about ${lib}.legal instead of current legal.${lib}?
> Thanks Joerg, for your important discovery and follow-up work.
> Yes i would rather work on "real" features, but i think that it
> is very important to have an efficient CVS, so i do not mind doing
> this type of work too.
But if there is no need for the one type of work you can do more of the
other type :)
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Bertrand Delacretaz wrote:
> Le Mercredi, 3 mars 2004, à 11:16 Europe/Zurich, David Crossley a écrit :
>
>> ...I wonder if it is true that almost every committer uses Eclipse?
>> I use command-line cvs.
>
>
> FWIW, I use IDEA, and often command-line CVS as well.
> The transparency of the command-line makes me feel safer ;-)
I have IDEA but had not time yet to try its CVS client (...it requires
to change cvsroot...), so I'm using command line.
Vadim
Re: whitespace cleanup and efficiency drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mercredi, 3 mars 2004, à 11:16 Europe/Zurich, David Crossley a écrit
:
> ...I wonder if it is true that almost every committer uses Eclipse?
> I use command-line cvs.
FWIW, I use IDEA, and often command-line CVS as well.
The transparency of the command-line makes me feel safer ;-)
-Bertrand
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
Joerg Heinicke wrote:
> Vadim Gritsenko wrote:
> >David Crossley wrote:
> >>
> >> The recent commit of all the *.license files proved that Eclipse
> >> is the culprit. Until their Bug 15119 is fixed (please vote for it),
> >> the Eclipse users should use the workaround to add the unknown
> >> text types.
> >>
> >> The find_binary_text.pl script reports these problems:
> >> .ai
> >> .css
> >> .dtd
> >> .gt
> >> .in
> > ...
> >
> > You know that you can use cvs admin to change keyword substitution, right?
>
> Of course, but you *have* to do it as Eclipse uses binary as default and
> not text like the command line cvs client. We never took care about it
> as it probably never was a problem. But since almost everybody seems to
> use Eclipse also for committing and especially adding files we had some
> issues in our CVS.
Thanks Vadim, yes we know that we can use 'cvs admin' - Joerg and i
have been doing that to manually fix the mess that people create by
using Eclipse in its current state.
I wonder if it is true that almost every committer uses Eclipse?
I use command-line cvs.
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.03.2004 14:34, Vadim Gritsenko wrote:
>>> We have quite a number of these problem files in cocoon-2.1
>>> I noticed a new one come in today with Carsten's commit
>>> of portal.samplesxconf
>>>
>>
>>
>> The recent commit of all the *.license files proved that Eclipse
>> is the culprit. Until their Bug 15119 is fixed (please vote for it),
>> the Eclipse users should use the workaround to add the unknown
>> text types.
>>
>> The find_binary_text.pl script reports these problems:
>> .ai
>> .css
>> .dtd
>> .gt
>> .in
>>
>>
> ...
>
> You know that you can use cvs admin to change keyword substitution, right?
Of course, but you *have* to do it as Eclipse uses binary as default and
not text like the command line cvs client. We never took care about it
as it probably never was a problem. But since almost everybody seems to
use Eclipse also for committing and especially adding files we had some
issues in our CVS.
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Vadim Gritsenko <va...@reverycodes.com>.
David Crossley wrote:
>David Crossley wrote:
>
>
...
>>We have quite a number of these problem files in cocoon-2.1
>>I noticed a new one come in today with Carsten's commit
>>of portal.samplesxconf
>>
>>
>
>The recent commit of all the *.license files proved that Eclipse
>is the culprit. Until their Bug 15119 is fixed (please vote for it),
>the Eclipse users should use the workaround to add the unknown
>text types.
>
>The find_binary_text.pl script reports these problems:
>.ai
>.css
>.dtd
>.gt
>.in
>
>
...
You know that you can use cvs admin to change keyword substitution, right?
Vadim
[1] http://blog.reverycodes.com/archives/000007.html
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Joerg Heinicke wrote:
> > Joerg Heinicke wrote:
> >
> > > I might be wrong but today I had the feeling that Eclipse just ignores
> > > the default -kkv set in Eclipse itself and adds every file with unknown
> > > file ending as binary. You maybe have to add your file endings at
> > > "Window > Preferences > Team > File Content".
> >
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=52333
>
> I made a better script which detects such problems in
> our CVS. It is now in the "committers" module:
> cvs/committers/tools/find_binary_text.pl
>
> We have quite a number of these problem files in cocoon-2.1
> I noticed a new one come in today with Carsten's commit
> of portal.samplesxconf
The recent commit of all the *.license files proved that Eclipse
is the culprit. Until their Bug 15119 is fixed (please vote for it),
the Eclipse users should use the workaround to add the unknown
text types.
The find_binary_text.pl script reports these problems:
.ai
.css
.dtd
.gt
.in
.jar-lincense
.jdo
.jj
.js
.jx
.license
.mod
.pagesheet
.samplesxconf
.svg
.template
.xconf
.xhtml
.xmap
.xmi
.xroles
.xsamples
.xsl
.xslt
.xsp
.xtest
.xweb
.xwelcome
Re: whitespace cleanup and efficiency drive
Posted by David Crossley <cr...@apache.org>.
Joerg Heinicke wrote:
> Joerg Heinicke wrote:
>
> > I might be wrong but today I had the feeling that Eclipse just ignores
> > the default -kkv set in Eclipse itself and adds every file with unknown
> > file ending as binary. You maybe have to add your file endings at
> > "Window > Preferences > Team > File Content".
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=52333
I made a better script which detects such problems in
our CVS. It is now in the "committers" module:
cvs/committers/tools/find_binary_text.pl
We have quite a number of these problem files in cocoon-2.1
I noticed a new one come in today with Carsten's commit
of portal.samplesxconf
--David
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 18.02.2004 02:32, Joerg Heinicke wrote:
> I might be wrong but today I had the feeling that Eclipse just ignores
> the default -kkv set in Eclipse itself and adds every file with unknown
> file ending as binary. You maybe have to add your file endings at
> "Window > Preferences > Team > File Content".
https://bugs.eclipse.org/bugs/show_bug.cgi?id=52333
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Joerg Heinicke <jo...@gmx.de>.
On 17.02.2004 07:09, Bertrand Delacretaz wrote:
>> The -k option is only for 'add' and 'update' etc.
>>
>> The default with the command-line client is to do ASCII and you
>> need to explicitly do 'cvs add -kb' for images, and jar files, etc....
>
>
> Note also that the binary -kb flag is set automatically when adding
> certain file types, based on patterns defined in CVSROOT/cvswrappers
> (which we cannot change, belongs to the cvsadmin group).
I knew this setting, but this is not the problem of our binary adds as
only few and really binary file endings are set there.
I might be wrong but today I had the feeling that Eclipse just ignores
the default -kkv set in Eclipse itself and adds every file with unknown
file ending as binary. You maybe have to add your file endings at
"Window > Preferences > Team > File Content".
Joerg
Re: whitespace cleanup and efficiency drive
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 17 fév 2004, à 06:17 Europe/Zurich, David Crossley a écrit :
> ...
> The -k option is only for 'add' and 'update' etc.
>
> The default with the command-line client is to do ASCII and you
> need to explicitly do 'cvs add -kb' for images, and jar files, etc....
Note also that the binary -kb flag is set automatically when adding
certain file types, based on patterns defined in CVSROOT/cvswrappers
(which we cannot change, belongs to the cvsadmin group).
See
http://cvs.apache.org/viewcvs.cgi/CVSROOT/cvswrappers?rev=HEAD
-Bertrand