tags:

views:

665

answers:

3

I'm trying to troubleshoot a post-commit hook script issue. I need to be able to try different solutions and see if they fix the problem by having Subversion run through its post-commit trigger -- this is critical because the problem lies with the particular user account running the post-commit script and its environment. (our setup is SVN/Apache, where Apache is running as LocalSystem on Server 2003)

Anyway, filling up the repository with bogus "test only" changesets is sub-optimal. Is there a better way to tell Subversion to pretend that a real changeset has been committed and to run through the post-commit script?

+1  A: 

When I have this problem, I set up a separate repository to test all my VCS magic. Then when it works, I copy the config over to my production projects.

For Subversion, here are the instructions on how to set up a new repository:

http://svnbook.red-bean.com/en/1.1/ch05s02.html

This way I don't have to pollute my real repository with fake commits, and I don't bug my fellow developers by breaking their real commits.

William Pietri
A: 

A couple of things I might try:

  • Move your script to start-commit and intentionally return a non-zero value so the commit doesn't happen. Depending on what you're trying to work out, this should replicate the environment close enough to debug.

  • Execute the script directly within a shell on the server.

Darryl
clever, thanks.
William Leara
A: 

Darryl solution to move the script to the start-commit seems fine.

To execute the script directly should be even easier using the "run as" option from the context-menu. Or even running "cmd" as the LocalSystem user and then executing the script...

Vargas