[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pre-commit transaction modification question

From: Brett Wooldridge <brettw_at_riseup.com>
Date: 2004-02-13 05:24:56 CET

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.


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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.