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. Help me help Subversion succeed in my
organization. I'm a senior developer, with 16 years experience, and a
good skillset, and I'm willing to help where I can to move Subversion
forward.
bw
Bruce Elrick wrote:
> Given the warnings about the server-side pre-commit hook changing the
> transaction causing WC badness, might I suggest you turn to using a
> wrapper on the client side? Implement the format check in the
> pre-commit hook as Ben suggested to prevent people from bypassing the
> wrapper on the client side, but on the client side write a wrapper
> that runs your formatter on appropriate files that are modified, then
> run svn commit from inside the wrapper. You can determine how
> sophisticated the wrapper has to be based on you user's trainability.
>
> That's my naive suggestion.
>
> Cheers...
> Bruce
>
> Brett Wooldridge wrote:
>
>> Ok, arguments about merits aside (as we've been using this model
>> under CVS for over a
>> year without issue) -- I'd still like to know how to accomplish this
>> under Subversion. CVS
>> has the same 'issue', in that after checking in the source, the
>> source in the repository no
>> longer matches the source on the user's system. Again, for our
>> organization, this has not
>> been an issue -- the only side-effect being that an immediate diff
>> will show the differences
>> in formatting, but after an 'update', the work is right again. So,
>> paternalism aside, can you
>> please help me shoot myself in the foot? :-)
>>
>> bw
>>
>> Ben Collins-Sussman wrote:
>>
>>> On Wed, 2004-02-11 at 17:18, Brett Wooldridge wrote:
>>>
>>>
>>>> Any help, pointers, and advice is appreciated.
>>>>
>>>
>>>
>>>
>>> DON'T DO IT.
>>>
>>> If the repository mangles the files as they enter the repository, then
>>> your working copy will be completely wrong. The working copy will
>>> think, "ah, this file I committed is what the latest version looks
>>> like", but in reality, the latest version in the repository is very
>>> different. There's no way for the pre-commit hook to tell the working
>>> copy that it mangled the data. What Subversion people have done
>>> instead is to install a pre-commit hook
>>> which merely *validates* a style, and rejects the whole commit if any
>>> file files to conform. This forces users to run the reformatter.
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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 Thu Feb 12 02:58:15 2004