In general, using the svnsync software should not end up with a "Corrupt representation" error message.
I wonder if:
1. you might have more than 1 version of Subversion installed on your server and the manual run is getting a different version?
2. there's something subtly wrong in the environment of the post-commit hook that is causing the error.
It's more likely #2 than #1 (of course, #1 is a subset of #2 - the PATH environment is different due to inheritance from Apache, SSHD, etc.
What I like to do to debug #2 is to output the environment from the post-commit hook into a file and then compare that file with what you have in your interact shell...
I also have svnserve running periodically on demand when clients need to connect using svn+ssh for transferring a lot of files. Would this cause the corruption problem? I'll try your suggestion on #2 as well.
Shouldn't cause any troubles. However, one thing that you saw over in the "svndev" mailing list is that you need to coordinate the running of the svnsync command so that there aren't 2 of them running at the same time. This *can* happen if simply run out of the post-commit hook because there's no coordination for those runs and if 2 updates come in very quickly then the simplistic approach would start 2 of them. Ick.
My work-around for this on Linux would be a Perl script that did "advisory locking" (e.g. "flock", et. al.) around the run of svnsync as a sub-process. Not sure how to do that on Windows.
What happens if two commits run at the same time and there is a lock on the file that runs the svnsync? Will the second post-commit svnsync not run at all and produce an error or will it wait till the lock is removed?
Also would an & after the call to svnsync.sh [B]&[/B] or after the svnsync sync file:///mnt/svn_mirror/ [B]& [/B]do any good if there is a lock being waited on? See code below.
Also I read that in order to have the post-commit complete and not wait for background jobs to finish, the output has to be redirected to /dev/null
e.g. svnsync.sh >/dev/null 2>/dev/null &
# svnsync.sh file
# lock code copied from web
# script running?
[[ -s $PIDFILE ]] && exit
# no, create pidfile
echo $BASHPID > $PIDFILE
# .. run svnsync
svnsync sync file:///mnt/svn_mirror/
# delete pidfile
Use of "PIDFILE" as a locking mechanism is deeply problematic as there is an inherent race condition: they can both check at the same time and then both write the PIDFILE itself (the 2nd overwriting the 1st). I strongly discourage use of the "file existance locking heuristic" as it is quite literally impossible to properly and completely implement. It worked fine when computers were SLOW but now, well, it's crap.
As for your original question, if you do the locking correctly (advisory locking on linux or strict locking on Windows) then both will run, serially, one after the other. The 1st will likely take care of both of them but just in case the 2nd will make sure of it.