Xapian devel - Feb 2007 - Re: [Xapian-commits] 7759: trunk/xapian-core/ trunk/xapian-core/tests/harness/

olly wrote:
> SVN root:       svn://svn.xapian.org/xapian
> Changes by:     olly
> Revision:       7759
> Date:           2007-02-26 18:38:13 +0000 (Mon, 26 Feb 2007)
> 
> Log message (3 lines):
> tests/harness/backendmanager.cc: Indent with tabs not spaces.
Hmm - this space thing is getting silly - I have my editor set to not 
expand tabs, but spaces crept in because I copied an indented line to 
start with, which was indented with spaces instead of tabs.  Doing a 
quick grep shows that lots of the code still has spaces instead of tabs 
- it might be worth doing a big global replace at some point, and then 
adding a test which checks that there are no lines which start with 8 
spaces in the source code.

For reference, the grep I used was:

rgrep '^        ' bin backends common examples include matcher net \
queryparser tests --exclude \*.svn\*

-- 
Richard

I don't really want to rant about this, which is why I just quietly
fixed the instance I noticed.  But since you ask...

On Mon, Feb 26, 2007 at 07:13:57PM +0000, Richard Boulton
wrote:
> Doing a quick grep shows that lots of the code still has spaces
> instead of tabs 
Restricting this to ".cc" and ".h" files, a quick grep
suggests that 623
lines start with 8 spaces, while 19593 start with a tab.  My tree isn't
pristine SVN head, but it should be representative in this regard.

The C source and ".lt" template of the lemon parser generator give a
lot
of hits to your grep, but this has a separate upstream - I've just made
a few changes so the generated code will fit better in our environment.
So we want to avoid unnecessary differences to make it easier to feed
back useful changes and merge in newer upstream versions (similarly we
wouldn't want to do a wholesale conversion of the snowball compiler
source code either).
> - it might be worth doing a big global replace at some point
The downside of this is that it hinders SVN archeology.  It would
add many "artificial" changes to the output of "svn
annotate", and the
last changed times for many files would end up newer than the last
time they were really changed.  And patches against SVN HEAD are less
likely to apply cleanly to the previous release.

So I've shied away from a wholesale clean up of the existing code.
I quite often end up poking about with "svn annotate" to find out
the history of bits of code, and the advantages of achieving consistency
don't really seem great enough to outweigh the annoyances.  But we can
at least try to converge on consistency.

If you want a script to check you aren't introducing more untabbed
lines, this does the job pretty well:

svn diff | grep '^+        '

Cheers,
    Olly