As an example of the kinds of CVS hooks I've seen in the past at places
I've worked, and
an example of where such modification might be considered desirable by
SOME users: the
last place I worked was very concerned about proper legal notices
(headings) being in files.
The legal department saw fit to change what they wanted in those headers
on what seemed
like a release-by-release basis. A CVS hook (in perl) was written that
inserted the legal
notice at the head of every file; if the notice that was there didn't
match the new one, it was
replaced. This was done at checkin, transparently to the developer.
Yes, I agree, to anticipate your arguments, it could have been
implemented as a header check
which rejected files with improper notices. Thus putting the onus on
developers to obtain the proper
notice and put it in files they checked in. To which I would ask
"Why?". Why should developers
have to do that if that is something that a tool can do for them. That
is why we have tools; to
help eliminate repeatitive and automatable tasks. If we had written a
'bad' hook that mucked up
the files, it's our repository, it's our fault.
This is like a basic liberatarian principle. Don't protect me from
myself. Let me have the power
and flexibility to make the changes I see fit in my environment. In no
way does this violate the
integrity of transaction or compromise the integrity of the repository.
It can be implemented in
a way that is completely transparent to the user and is literally a
no-op when the transaction
goes un-modified.
bw
Philip Martin wrote:
>Brett Wooldridge <brettw@riseup.com> writes:
>
>
>>Would it be possible for the server to pass the new checksum back to
>>the client in the commit-response?
>>
>>
>
>Just about anything is possible if someone is prepared to design and
>implement it. Are you proposing that the file I commit gets modified
>by the repository and then my working copy version of the file gets
>changed to match that in the repository? That would mean that the
>exact version of the the file I committed (the one I tested) gets
>lost. Will your pre-commit run build and regression tests with the
>modified file to verify that the changes are sensible? I guess that
>might be academic, if your developers cannot format files correctly
>they probably can't write regression tests.
>
>I can see that the idea of modifying the txn in pre-commit is
>attractive, I have yet to see an example where I would want it to
>occur in practice. I suppose it might work for something like
>automatically modifying a file not otherwise involved in the
>transaction, accumulating log messages in a Changelog file perhaps.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 13 05:25:15 2004