Re: Post Commit Hook Script !!

On Fri, Jul 29, 2011 at 3:17 AM, Himanshu Raina
<raina_himanshu_at_yahoo.com> wrote:
>
> Hi,
> The post-commit script isn't getting executed whenever code is merged from trunk to tags.
> Whenever the code needs to be deployed the code is copied from trunk to tags. The script runs
> fine when executed on the server but doesn't get invoked whenever a commit is done.

Hook scripts in Subversion don't get executed locally. They are only
executed on the server. This has advantages and disadvantages:

ADVANTAGES

* Your hook script only has to work on a single machine -- the server.
You don't have to worry whether a developer's machine has the software
needed to execute it.

* Developers have no way to get around a hook. In ClearCase,
developers could munge their machines to get around hooks because the
hook was a local process.

DISADVANTAGES

* You don't have direct access to the developer's working directory.
That's on another machine. All you can do is examine the code which is
part of the hook. You can't munch code for the developer. You can't
reformat files. All you can do is prevent the developer from
committing a change. (Actually, this is a big advantage because this
can't become your job. It's up to the developer to verify their code
before a commit.)

* You can't be interactive. All you can do is give back a post-execute
message in STDERR, and only if the commit itself failed. You can't ask
for defect IDs or if they want to deploy the code to QA, etc.

It appears your hook script is interactive which is an issue. That's a
no-no. The other issue is that you can't do too much -- even in a
post-commit hook. That's because the client has to wait for the script
to finish before it can return control back to the developer. If your
post-commit hook takes more than a could of seconds to run, you should
reconsider what you're doing and move whatever task farther down the
line.

I suggest you look into continuous build software -- even if there is
no "build" involved with the software you're producing (for example,
it's all scripting or webpages). That's because a continuous build
server can do more than build the software. It can deploy to
production, check the code for formatting, and run unit tests. It can
then return the results to the developer.

--
David Weintraub
qazwart_at_gmail.com