RE: Automatic pretty-print

-----Original Message-----
From: David.Stagner@mpls.frb.org
Sent: Thursday, August 19, 2004 10:38 AM

The thing i don't like about doing pretty-printing as a checkin hook is that
you then have not built and tested EXACTLY what is getting checked in.
Developers shouldn't be checking in code without building and testing first,
right? Make the pretty-printing part of the build process. Have a 'make
pretty' target that finds all writable relevant files and pretty-prints
them, then does a make clean; make test to assure they're good. Developers
are then required procedurally to do a make pretty before committing
changes. That way, you don't require Subversion to do something it doesn't
and probably shouldn't, and you don't check in untested changes. Peer
pressure can enforce little things like that.

---
This sounds eerily like the solution my previous team applied in our CVS
environment (which I intend to adopt into my new team's fledgling Subversion
environment), which was to have an "indent" script and a "prep_proj" script
as part of our project environment.  Developers were free to format code
however they liked and to run the indent script whenever they liked, and
process dictated that running prep_proj was mandatory before checkin--and
the first-step of prep_proj was to run the indent script.  The project was
rebuilt if the indent script altered any files, and all the unit and
functional tests were run.  A successful run ended in a diff against the
repository being produced (for code review), at which time the developer was
free 'n clear to check in the project.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org