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
Received on Thu Feb 12 00:48:53 2004