The hook runs when I commit; the directory exists; and the user it's run as has the correct permissions to access the directory (I've tweaked the code for the hook to echo both to the log file to check.)

When I su to the user, and change to the directory, I can run svn update - it will update with the latest revision. When I do it through the hook, it won't.

I've done some poking, and discovered that when the hook is run, svn update is triggered; but it's not doing anything with the new revision that's just been committed. I removed a file from the target directory, and commited a change - the file was restored, but from an earlier revision - the last revision I'd updated manually, in fact.

There's clearly something odd going on, but I can't figure out what. The configuration of the repository looks OK, but I don't know enough about SVN to narrow it down any further. I'd appreciate any hints anyone might have as to where to look next.

The output from the logfile isn't helpful; when I just commit files, I'm seeing:

Mon Jun 17 10:05:08 EDT 2013

Which was the time the commit was last made. svn update is not outputting anything into the log file.

I've just created a new revision - I've added a new file to my local copy of the repository, and deleted README from the target directory. That gives me the following in the log file:

Mon Jun 17 10:11:44 EDT 2013
Restored 'README'

The revision I've just commited was 134. There's no sign of the new file , and svn info tells me that the Last Changed Rec is still 132.

Edit, again

I've added some debug code to the hook, as requested:

echo $@ >> /tmp/tempfile;
env | tee -a /tmp/tempfile;

This gives:

/srv/svn/repos/sitename 150
OLDPWD=/
PWD=/srv/www/sites/sitename

150 is the revision I've just added.

Edit, again

As requested. The first one is from when I made a change and committed it (nothing was updated); the second is after I deleted a file, and committed again (the file was restored, but from an earlier version)

I've created a new working directory, while logged in as www-data. I did the initial checkout as the same user; and then committed. And svn update didn't do anything.

I'm as sure as I can be that this isn't an obvious file permission error. The hook is definitely running the svn update command, because when I delete a file from the working directory and run a commit, it's restoring the file I deleted.

It's as though svn isn't seeing the new version. The command I'm currently using in the hook is:

$1 is the right repository name. $2 is the correct, latest, version number. $WC is the correct directory.

When I commit a file, the hook is run, but doesn't update (even with the -r flag set).

When I run svn commit as the right user, in the right directory, it updates properly

When I delete a file from the working directory, and commit, that file is restored, but from the most recent revision run manually.

And in the interest of completness, I've also tried using older versions of the revision number. When I did /usr/bin/svn update -r 10 "$WC" 2>&1 [that's about 140 revisions ago], it made no changes - nothing deleted, nothing added.

Update the fifth

Adding the svn update into cron did exactly the same as when it was started off by the post-commit hook; it would update to the last version I'd run svn update for, but newer revisions would be omitted. If there were no differences between the working directory and that last version, it would do nothing. And yes, cron was being run. I tried this both as the correct user, and as root, being somewhat frustated at that point.

Additionally, I've just recreated the repo and the working directory. I added the content from my local working directory to the new repo, and it's behaving exactly the same way. Even though the setup is identical to a different development site which I set up this morning.

So I'm giving up at this point. The hassle involved in trying to fix this properly far outweighs the inconvenience of having to update it manually occasionally. Thank you all for reading this, and for your suggestions.

is there anything interesting in your log.txt? maybe adding the output of svn info to the logfile helps.
–
krissiJun 17 '13 at 13:59

@krissi - thanks for the response. I've added some of the output from log.txt to the question, for what it's worth, as well as svn info.
–
andrewsiJun 17 '13 at 14:15

Perhaps you are having an issue with the environment or permissions of the user who runs the script? Try adding env >> logfile or something similar to check how the executing user's environment looks.
–
user160910Jun 17 '13 at 14:34

Try to add -r to your update command: cd "$WC" && /usr/bin/svn update -r "$REV" 2>&1 >> "$REPOS/hooks/log.txt". I use it in my scripts. I also replaced the command with the absolute path.
–
krissiJun 17 '13 at 14:36

@krissi - the -r didn't help, I'm afraid - there was nothing output. I know it's not an issue with the path, because svn update is running - it restored the file I'd deleted. It's just not picking up the new version.
–
andrewsiJun 17 '13 at 14:43

1 Answer
1

Why not have a cron job run every few minutes to update the working copy. It will circumvent the trouble you are having doing this as a post commit hook and it will save the developers the trouble of having to wait for an svn update to complete every time they commit.

I give up. I've just added a new cronjob, with the single line /usr/bin/svn update /srv/www/sites/sitename. It doesn't do anything - it's run, but there's no output. When I cut and paste the same line from crontab to a prompt, it works. I've tried this as the correct user, and as root. I think I might just make the developers request updates at this point.
–
andrewsiJun 17 '13 at 20:03

Thank you very much for your help with this. I do appreciate it, even if we get to the bottom of it.
–
andrewsiJun 17 '13 at 20:06

You sure cron service is running? I would probably put it under /etc/cron.hourly.
–
user160910Jun 17 '13 at 21:18