I have a thought on this topic that may cause even more of an uproar...
How about doing a test in your pre-commit hook. If the code has not
been run against your electronic formatter, then fire off a separate
script that modifies the script and does yet another commit. It will
require a working copy for the script to work against, but it works when
I run it in my head :-).
Yes, Yes - I know that it will now show as out of sync from that
individual who checked it in, but that little bit of education (if you
format properly, you stay in synch. if not, you will be out of synch)
is a trade off for trying to automagically reformat code on a commit.
General structure of the flow:
[pre-commit]
Code test - did they format it properly?
yes = continue
no = execute a separate external program (codeformat)
ALWAYS allow the commit to be performed.
[codeformat]
Update local working copy
Run the code formatter on the files in the previous commit.
Perform a subversion commit (create a separate, internal user to
recognize the process that did this formatting)
Generate a message to log / email alerting you that the external
format was triggered. You could then take whatever corrective action
with the developer.
With this done, you would satisfy your requirements of the formatter
being run, subversion stays happy with commits done by 'users', and the
only thing negative that occurs is the developer who did the check-in
thinks they are out of synch. Big whoop - they can do a quick update if
they are bothered by this (which they should be, but it should be a fast
update).
Regards,
Frank
Servico Tpd Rodrigo Alfonso Menezes Madera wrote:
>
>
>Dear Steve:
>
>This is what we would call "using power against employees". I preffer to
>use my authority, making people do what they think is right for them. Iīm
>nobody to force anyone to work my way just because I think Iīm correct and
>that my way is the best way. Programmers are sensitive people, and code
>style is a religion to most of them.
>
>So, let everybody convert their code to their style. Work on their style.
>Compile on their style. And when they just run indent with the standard
>(that was created by them via an election, btw) and it will be all ok.
>
>Now please donīt get me wrong, but human beings werenīt made so they would
>be punished-if-not. Thatīs the big difference between making your team
>respect you and making your team fear you. And you must respect your
>programmers, they are your company. They are your biggest treasure.
>
>So my point is, give them freedom to work the way they feel confortable.
>Some of them dislike shoes... thatīs programmer stuff. Respect that. The
>only thing that we should do is improve the system so programmers remember
>to run the standard format. Itīs not the standard because I started the
>company, but because the programmers liked it and agreed upon it. But it
>never really gets seen. They indent it when going out and latter before
>getting in.
>
>As of now, the best solution presented was the first one, where we copy
>each commit candidate and run indent to see if itīs already formated.
>
>Thanks to all of you,
>Rodrigo Madera
>
>
>
>
> Steve Williams
> <stevewilliams@kromes Para: users@subversion.tigris.org
> tudios.com> cc:
> Assunto: Re: Formating C/C++ code before commit with indent
> 21/06/2005 20:01
>
>
>
>
>
>Servico Tpd Rodrigo Alfonso Menezes Madera wrote:
>
>
>>All of our C/C++ projects follow a well defined format (wich can be
>>represented via indent params) and we wish to run indent just before the
>>commits. This is important because our programmers very different setting
>>in their editors such as tab spaces and formatting styles. The indent
>>program handles this ok. It just has to be executed before the commit.
>>
>>
>
>Our solution is to enforce the coding style on the programmers. If you
>work here, you will code using the company's coding style. If you
>repeatedly disregard the accepted coding style, it will affect your
>annual staff review. It's just a matter of user education.
>
>--
>Sly
>
>
>This message and its attachments may contain legally privileged or
>confidential information. This message is intended for the use of the
>individual or entity to which it is addressed. If you are not the addressee
>indicated in this message, or the employee or agent responsible for
>delivering the message to the intended recipient, you may not copy or
>deliver this message or its attachments to anyone. Rather, you should
>permanently delete this message and its attachments and kindly notify the
>sender by reply e-mail. Any content of this message and its attachments,
>which does not relate to the official business of the sending company must
>be taken not to have been sent or endorsed by the sending company or any of
>its related entities. No warranty is made that the e-mail or attachment(s)
>are free from computer virus or other defect.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
Received on Wed Jun 22 15:36:43 2005