svnsvn-hookssvn-server

svn hook to generate file from committed files

I have an SVN repository that has 

trunk/file1.txt
trunk/file2.txt
trunk/fileR.txt

On the server, I have a working copy checkout of trunk ( /var/www/trunk ) owned by user www-data .

fileR.txt is read only for everyone except the user www-data (access restricted by authz or svnlook author). fileR.txt should be generated by concatentating file1.txt and file2.txt: cat file1.txt file2.txt > fileR.txt

What I want is that every time there is a commit on either trunk/file1.txt or trunk/file2.txt, a script should be run that updates the working copy on the server, concatenates the files and commits the new fileR.txt to the repository.

What I had in mind was a post-commit hook that does all of the above, but I am not sure if and how SVN can handle a new commit until the previous commit has been finalized.

Example: So, commit1 with changes to file1.txt comes in, pre-commit hook runs (if any), transaction is committed to the database and then the post-commit hook runs. The post-commit hook actually creates a commit2 that needs to finalize before the post-commit hook from commit1 will actually finish.

Is SVN capable of doing this? If not, what other tools / workflows do you suggest?

Thanks

Solution

  • Let's say you make a post-commit hook to do what you want...

    1. I commit a change in file1.txt.
    2. Post-commit hook picks up the change, and creates a new file fileR.txt
    3. Post-commit change commits this change which causes your pre-commit hook to fire.
    4. And, you're right back to Step #1

    There's also the issue of creating a working copy on your server where your post commit hook can operate. When someone does a commit, you'll have to either update or even checkout a working copy on your server, concat the changes, and then do a new commit without firing your commit hook. Remember, people might create branches, so you may have to have multiple working copies.

    And, while your post-commit hook is doing all of this, you users have to wait for the post-commit hook to complete.

    Plus, if I do a commit, my working copy is now out of date. I now have to commit, then do an update because the server did a commit.

    I hope I've convinced you that this isn't a really good idea. It is possible, but it certainly isn't advisable. In fact, if I saw a build engineer do something like this, I'd fire them.

    I suggest you take a look at Jenkins. Jenkins is a continuous build server. What you can do is have Jenkins create your fileR.txt file for you whenever a commit is done. This file can be easily downloaded from the Jenkins server and be made publicly available. You can also maybe take your fileR.txt and create the PDF for people while you're at it.

    So, your combined file is still available and can be downloaded by your other processes, but it won't cause your post-commit hook to fire another round of hooks. And, fileR.txt is read only by everyone who has access to that particular Jenkins job.