On Fri, Jul 29, 2011 at 3:17 AM, Himanshu Raina <raina_himan...@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 qazw...@gmail.com