On Mon, 6 Jan 2003, Robert Leland wrote:
> I suggested before having the code
> automatically formatted when a checkin or
> checkout happens.
Based on past experience, I'm not too comfortable with this idea. I had a
similar experience to Craig, and also found that some things just didn't
work out properly when left to an automated tool. Getting the formatter to
agree with the analyser was harder than we expected. ;-)
I would argue that once the code base has been brought into compliance
with the agreed coding conventions, and a tool is in place to easily
verify such compliance, the need for an automated process is significantly
diminished.
In any case, I'd prefer to separate the discussion of a set of coding
conventions from the discussion on whether or not to automate them around
the checkout/checkin process. I think we need to do the former first, and
then we can talk more about the latter.
--
Martin Cooper
>
> This could be done in 2 places:
> 1) The Jakarta script that
> checks to see if a user has access to one of
> the Jakarta projects.
>
> 2)CVS provides hooks/calls to be made
> before or after any check out, or checkin operations.
>
> The wrapper could look for the existance of
> ${Project}/conf/format.dat
> where Project = jakarta-struts in our case
> and if the 'format.dat' file exists automatically format the
> code if it is a .java, .xml, or .xslt file.
>
> Formatting on both checkin & checkout has the
> advantage when doing a CVS diff between
> an earlier version if struts code that wasn't formatted,
> and a current version that is formatted.
> In both cases both versions are in the same format.
> Also if we change the formatting over time, all
> previous versions would presented in the most current version.
>
>
> -Rob
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
