[postgis-devel] Astyle bot

[Paragon Corporation]

Chris,

I agree. I think it's a bit overrated and I think our code is fine even if
slightly different as long as it looks more or less consistent.  Paul and
Mark seemed the most bothered about it. It and of course we had farcical
fights over coding format before we settled on one.   Both Paul and Mark
tend to be a bit  anal about these things. :). 
Strk is probably not happy because he's a space guy I think. 

I think running astyle before a release is sufficient if it is really a
concern.  My diff ignores white space anyway so doesn't pose a problem for
me comparing prior code but only an issue when I try to click the tab and
some space guy had his way.


We do have an Astyle.sh in our code base, which is what I ran.  It requires
running 1.23 because I think when Olivier had formatted with 1.24 he
discovered it reastyled everything.

I normally would just use the built in one in my editor, but have no clue
what version it is compatible with and surprised why a rule of formatting
should change from version to version so much.

Perhaps we should just remove that line from the committer guidelines  and
say "Try to follow our Astyle guidelines to the best of your ability".

Thanks,
Regina

-------- ORIGINAL MESSAGE --
I'm not sure if this is the 4th or 5th time this has come up...

svn hooks are not supposed to change the code that is being committed. 
The reason for this is that there is no way to communicate those changes 
to the client. The unformatted version of the code in your sandbox, 
after you commit, is revision X, and the version of the code which was 
automatically formatted and put in the repository is ALSO revision X. 
This causes future commits to potentially fail, and there is NO WAY to 
update your client because it thinks that everything is happily the same 
updated version as is in the repo.

We could do an automatic process to go in after an update and checkout 
any changed files, restyle them, and commit them, but then our SVN 
history is full of "restyle" commits. This causes confusion when looking 
for "who/what broke the build?" and generally just seems messy to me... 
comparably messy to just having an irregularly styled codebase.

What we could do is put a pre-commit hook in SVN that runs astyle and 
looks for changes - if there are any, then the commit is rejected, and 
you have to run astyle yourself before committing. However, due to the 
apparent lack of compatibility between versions of astyle, this doesn't 
seem to work either. Perhaps we could include a version of astyle or a 
similar script inside postgis? Similar to including autoconf-generated 
tools. Then we can ensure that the same formatting is being run on both 
the SVN server and all clients. I don't know whether this is possible 
with astyle or if there is another tool that could do it?

Not to start a holy war but I don't really have a problem with 
formatting in general. Compared to Mapserver, the PostGIS code looks 
great! But then, more developers == more differences. So anyways I'm 
pretty indifferent about the "solution" to this "problem".

Chris