views:

415

answers:

2

Our repository has a structure like this:

Dev
    Project1
        source
        docs
        ...
    Project2
        source
        docs
        ...
    ...

After we commit changes to Project1 sources we would like to deploy Project1 (compile, test, copy, etc.). How to find out in post-commit-hook that we commited to Dev/Project1 so we could export this project and run some tasks on it? When commiting to svn (e.g. using TortoiseSVN) ir is written: "Commit to: ..." How to find that "commit to"?

+1  A: 

You should use

svnlook changed -r REV REPOPATH

in a post-commit hook. SVN will provide REPOPATH and REV as arguments. You get a list with all changed paths back(new line separated). You can then easily use grep or anything else to search for the changed paths.

Remember: start a new thread for building/deploying, as svn will wait until post-commit hook has finished(so you will not see "Committed Revision XX" until everything is deployed).

Peter Parker
Ok, when I get all changed paths, how do I find base "Project"? And how to start new thread for deploying in post-commit hook?
Sazug
Peter Parker
We are using Windows :)
Sazug
you should use some script language as post-commit-hook, as perl, python or vbscript. I do not know how to start another thread, but it should be easily possible in windows
Peter Parker
To start another thread you should use the "start" command as last line in you batch script: "start test_deploy.bat"
Peter Parker
"Start" does not work on Windows, see http://www.nabble.com/A-solution-for-starting-background-jobs-on-Windows-from-post-commit-hooks-td20461573.html
Sazug
Oh, shame on me .. I just tested it. You are right, sorry for my wrong advice.
Peter Parker
To start the post-commit hook in an asynchronous mode on windows, the easiest way is to call a vbs (visual basic script) from your postCommit.bat and then from the vbs to call your program. This is how I did it and it works very well, the user doesn't have to wait until the hook terminates.
Victor Ionescu
+2  A: 

I would recommend using a continuous integration server like CruiseControl.NET over using a post commit hook for integration tasks.

These tools can easily monitor your repository for changes below specific urls, but they don't have to be run with the same privileges as your subversion server. In particular they can never corrupt your repository. You can just run them on any (old) server, while you can run your repository on a more prominent/stable/backed up server.

Bert Huijben
you are right, Continuous Integration is the better solution (+1 for this) for his problem, however, I referred directly to his headline and his question.
Peter Parker