Brett Wooldridge wrote:
> I appreciate the suggestion, the problem is that some users use
> Tortoise, other's Eclipse integration, and other's still (those hardcore
> emacs users) command line. Getting people to voluntarily format their
> code was tried and was a miserable failure (at least is our
> organization) -- you know, herding cats and whatnot. A style checker is
> only slightly more attractive, and would probably last about five
> minutes until developers started complaining to their managers about
> having their code rejected five times and what a burden it is on their
> productivity. We have some coders with truly awful style, and
> management has the spine of a noodle -- so if it isn't painless for all
> involved, it's not going to fly. So far, CVS has served us very well in
> this regard. I really want to move our organizationto Subversion, I
> believe in it's principles, I see value in it's features, and I want to
> see it thrive -- but it can't represent a step backward for the
> processes that we have in place.
Is it okay if a checkin generates two versions of a badly formatted
source file, the ugly one exactly as checked in by the user and then a
clean one?
If so, you could write a little script that is triggered post-commit.
It would svn update its own working area on the server, see if any files
that were just updated matched the criteria for needing reformatting
(e.g. "*.java" or "*.c"), run the correct formatters on those files, do
a svn diff to see if the reformat actually changed anything, and do a
svn checkin if necessary with a standard commit message like "janitor
bot cleaning up after $USER's checkin r1234"
The developer who just did a checkin would have to do an svn update to
get the formatting changes, but if he forgot and kept working on the
ugly files, it would be a trivial merge later. Users who didn't like
this would have incentive to run the formatter locally before checking
in files.
--
David Ripton dripton@ripton.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 9 00:15:55 2004