Re: Pre-commit hooks and access to files

On Mon, Aug 17, 2009 at 7:05 PM, Douglas Bullard <dbullard_at_nurflugel.com>wrote:

> I'm investigating whether it's possible to modify the contents of
> files in pre-commit hooks (such as inserting author's names and
> revision numbers in class comments, etc).

There are three answers to this particular question:

1). No
2). Yes
3). Don't even think about doing it.

Let's take Answer #1: You cannot modify the files in the commit itself. You
can examine the files with the svnlook command, but you can't modify them.
How could you? The working copy is sitting on the developer's computer, and
the hook is running on the server. You simply don't have access to the files
in order to modify them.

Now, let's look at Answer #2: Although you can't modify that particular
commit itself, it is technically possible to have your hook script do a
fresh checkout, modify the files, and then commit those changes. The end
results are pretty much the same as modifying the files on a commit.

Now, let's look at Answer #3, and why you should never, ever even think of
doing Answer #2:

Modifying the committed files will mean that the user who just did the
commit will now find their working directory out of date. Plus, you now are
going to have two commits for every developer commit: The one the developer
did, and the one the hook script did. It makes tracking down changes quite
difficult.

And, then there's the actual machination involved. First of all, when your
hook script makes the changes, and does a commit, it will end up calling
itself again. This can lead to your hook script going into an infinite loop
as it checks in the changes over and over again. Then, there's the time it
will take for you to do a checkout, modify the files, do a second commit,
and then run through your hook script again. The developer will have to wait
as you do all of this.

And, don't forget that you could have multiple commits going on at once --
especially since now each commit is going to take much longer. That means
you'll need separate working directories for each commit.

Plus, what happens if your modifications actually breaks the build? The
developer makes their changes, tests, and does a submit. Now, suddenly the
code doesn't work and may be impossible to fix until you turn off that hook.

And, you very well know the developer will still blame your hook script even
if they checked in bad code from the start. "It wasn't my fault! That hook
script changed it and broke it!".

So, no you can't modify the commit on a pre-commit hook, and even if you
could, it is still a lousy idea.

If you are simply looking into this for yourself, you now know everything
about the dark art of commit modification and know it should never be
practiced. If a coworker was asking you to investigate this, tell them that
it's simply not possible. Period

I've been a SCM for almost two decades, and I've used lots of SCM tools.
Some tools (like ClearCase) run hook scripts on the client's machine and not
the server, so it is very easy to modify files being committed since you
have direct access to the working directory. I've fallen for this trap with
disastrous results. It simply is asking for trouble.

If you are trying to figure out who modified or wrote a class, you can use
the "svn blame (aka "svn annotate" and "svn praise") command. This will show
you who modified a particular line and the revision that line was modified
in.

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2384902
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].