What I need is a SVN post-commit hook that must be able to create (not to just trigger the run) its own Jenkins Job (if the revision ID is 0), and it has to be executed on multiple project. Basically, each project must be able, using this hook, to add its own job in Jenkins the first time it's committed. What I need to know is how to give to Jenkins the repository URL for each project, using always the same hook.
When you run a post-commit hook, the committer has to wait until the commit is complete -- which means waiting until the post-commit action itself is complete. If this takes too long, and too long can be a few seconds, the users will revolt. Imagine every time you do a commit, the commit takes 15 extra seconds. Fifteen seconds of you sitting there not knowing what's going on. How long will the user wait until they start trying to terminate the commit?
You can duplicate Jenkins jobs and update the config.xml of a job through the Jenkins REST API. It's not trivial, but it's possible. However, this is not the mechanism that you want to use.
Instead of having dozens of Jenkins jobs that build the project's sub-tree in your repository, have a single Jenkins job that builds the project's sub-tree that was modified.
Imagine your Subversion URL for project foo is http://svn.vegicorp.com/projects/foo and your Subversion URL for project bar is http://svn.vegicorp.com/projects/foo. You could setup a Jenkins job to monitor http://svn.vegicorp.com/projects, then see whether foo and/or bar have been modified, and then fire off the build for that particular sub-tree. When someone creates project http://svn.vegicorp.com/projects/fubar, Jenkins will watch over that project too since it's already looking at http://svn.vegicorp.com/projects.
You can use the Build Name Setter Plugin to set the name of the build to the sub-tree that was built. This will let you see which builds were for which projects.
This should be much easier to setup in Jenkins than trying to create on the fly Jenkins jobs.