[postgis-devel] Astyle bot
lr at pcorp.us
Fri May 13 21:15:15 PDT 2011
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".
-------- 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".
More information about the postgis-devel