> At 01:32 PM 12/1/2005, Mark Shead wrote:
> >way your coders have a simple way to format everything correctly and
> >can use a pre-commit hook and the checkstyle tool to reject any
> >where they forgot to run the formatter.
> Commits isn't the only place where different coding style may become a
> problem. A diff between the working base and the working copy can
> screwed up by reformatted code.
I think you can specify a different diff program and tell it to ignore
white space. The gui diff program that comes with Tortoise does this.
At least it works with spacing changes within a single line. I've never
tried it on code where all of the layout had changed.
> I understand that I may need to adopt a coding standard in order to be
> compatible with Subversion. But that was exactly my question: is
> way to make Subversion work the way I want? If the answer is an
> and definite 'No' then I'll have to change my ways. But then this
> to me as the case of making a developer jump through hoops because
> aren't flexible enough instead of having the tools making the
> life easier (not that Subversion hasn't eased our lives by so much
> :-), but we always want more).
There was a discussion about this last year here:
It sounds like even if it possible to change the files in a pre-commit
hook, it could break some other things and render your working copy
I've seen several messages that suggest that it is possible to modify a
file being committed using a pre-commit hook, but so far I haven't seen
any examples. So while it might be technically possible, it may involve
writing a lot of code.
In my opinion, on of the reasons for having a coding style in the first
place is to reduce the number of bugs due to sloppy formatting.
Formatting it after it is submitted would negate any of these benefits.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Dec 2 14:50:24 2005