Should a call to SVNSYNC be blocking or not in a post-commit hook?

Hello - this is my first question here and in fact one moved from StackOverflow as I think this site will be more in sync with the topic.

I've set up mirroring of my repository and it works nicely but I've had an issue recently.

The target repository was left with an unreleased lock somehow - from what I read this may be caused by an abort to the svnsync operation and I suspect it may be because in my post-commit hook I'm executing svnsync in blocking mode rather then pushing it into the background via &.

I do this so that the user can be sure that if the commit finished then it's in all repositories now but maybe it introduces a risk of them hitting cancel and stopping the commit hook?

I can't find clear guidelines or suggestions on which is better or what the best practice is or even if hitting cancel can cause an abort of the post commit hook and the sync executed from it - in most places I see people using & to kick of the sync in the background - does this prevent the lock corruption in case a user presses cancel to his commit while the sync is in progress? How do you make sure both repositories are really in sync or report issues? Do you need a separate notification mechanism for that?

Update:

From the two above options I decided to chose the third ;)

I'm calling svnsync in the background but at the same time I make the hook wait for it to finish:

svnsync ... &
wait $!

I think this nicely joins the best of both worlds but time will show how effective it'll be - please let me know what you think about the whole issue and what suggestions you might have to share about it.

Update2: It did not fix the problem - apparently when the hook is killed it also kills it's child processes :(

Would anyone have any tips on how to tackle this? I'd really like my users to be able to know and trust that when they see the commit complete it means all sites are in sync.

From serverfault RnR

• I would consider moving this from a post-commit hook to an incrond task, which would use inotify to monitor the repository for changes and then run the svnsync task.

  As a more modular setup, it would provide me with more flexibility with a unified configuration - i.e. I wouldn't have to keep updating various users' post-commit hooks.

  RnR : This will not work - I need the users to be sure that once they finished the commit all the mirrors are in sync - working in a cron job works in a backup scenario but it's not the case with what I have (a read caching mirror - the cache has to be up to date at all times)

  Docunext : Incrond isn't a cron job, its an live modification watcher built into the kernel, so it might even be faster than the post-commit hook. :-)

  RnR : Its not about speed but atomicnes of the operation. When its blocking your commits end when all sites are in sync and thats what I need. Can you do it this way?

  Docunext : I appreciate what you are aiming for! Its a worthy goal, but in my experience svnsync just isn't robust enough - my guess is that it halts the sync to prevent corruption of the replicated repositories. I can't tell you how many times I've run into that unreleased lock problem, so I gave up on it. Could you elaborate on why you are trying to do this, and what you are trying to avoid with the atomicity?
  From Docunext

• Unfortunately I can't really say the question has been answered. Only thing that comes to me right now is setting up a synchronization service that would be doing the synchronization and having the hooks initiate and wait for the sync by communicating with this service but not being it's parents thus not having the potential problem of a cancel terminating such a sync while it's in progress.

  From RnR