2
votes

I am trying to implement a post-commit hook to update a working copy. As far as i can figure out the post commit hook is being run (I wrote something in a file to verify it) but the update command was not run.

At first I did

cd /home/user/working/copy
svn update

but that didn't work, then I read you have to give the full path to svn:

cd /home/user/working/copy
/usr/bin/svn update

but still it failed to work.

I changed permisions to 777 and have run the script in an empty enviroment ... and it works.

8

8 Answers

5
votes
#!/bin/bash
/usr/bin/svn update /home/user/working/copy

The above code should work as a post-commit hook.

Add --username & --password options if needed.

Edit:

See http://subversion.tigris.org/faq.html#website-auto-update

The server program performing the commit (svnserve or apache) is the same program that will be running the post-commit hook script. That means that this program must have proper permissions to update the working copy.

If the 'working copy' that needs to be updated is owned by the same user, then you need NOT worry about username & password.

The Subversion FAQ suggests using Setuid with the following C program.

#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
    (const char *) NULL);
return(EXIT_FAILURE);
}
1
votes

The working copy is in a user's home directory. If the SVN server runs as a different user, say "svnserver", then the post-commit hook script will run as "svnserver". It makes sense that one user cannot modify or read another user's files unless the permission settings on the files are such that this is allowed.

You should not share working copies among multiple users. If you really must, then simply giving read/write permission to each user is not enough. You would also need to make sure that none of the users create files which are inaccessible to other users. To achieve that you would need to write wrapper scripts for the svn commands that set the proper umask, or give all involved users the ability to act as one specific user through sudo.

1
votes

If you do not use the workingcopy by yourself, you can chown the workingcopy to the user which runs the hook-script

1
votes

I also run into same issue, and tried (including the one in official FAQ) all method with no luck

of course, I also run chmod -R and chown -R www-data:www-data as needed each time.

In most cases, update command executed, no permission error, no any other error message, but working copy is not updated.

finally the steps below works well for me:

in post-commit hook run

export LC_CTYPE=en_US.UTF-8
cd [/working-copy-folder/] # heading tail slash
/usr/bin/svn checkout [source path]

once, then update post-commit hook to

export LC_CTYPE=en_US.UTF-8
cd [/working-copy-folder/]
/usr/bin/svn update

now it's working, and I am too tired to find the root cause. spent whole day on just 'svn update'

0
votes

the final solution that i got working was a mix some of the answers i got. My server had apache running as nobody, so i made the working copy be owned by nobody and in the group UserName and then chmod it to 775. This way the hook will work and also the username will also have permision to update files by FTP.

0
votes

wcoenen's answer is definitely on the right track. The easiest way to get around this problem would be to add the SVN user to your group. Let's say your post-commit hook is owned by user someUser and group someUser. Adding the SVN server to the someUser group, and chmodding your post-commit hook script to be group-executable, would solve your problem.

I hope that made sense :P

0
votes

This script is better because it updates only required files... http://vidax.net/blog/en/2010/03/subversion-post-commit-hook/

-3
votes

I believe the post-commit actually is run before the commit is made visible. It's strange, but say you committed revision 30. The post-commit would still see 29 as being the latest revision. Once the post-commit script is done, you'll see 30 as the head revision.

I could be wrong. This is strictly from memory. Something to try at least.