On Fri, Nov 27, 2009 at 12:57:09PM -0000, Jon Foster wrote: > Stefan Sperling wrote: > > There is a much worse race condition, however. > > Yep, your mail arrived whilst I was testing this race condition in > a debugger. I can confirm it's a real bug. > > But for me, the biggest problem with svnsync's locking right now is > that if the network connection between the servers fails during > a sync, then the lock is not released.
Yes, that's another problem of the current locking approach. svnsync clients should be registering with a locking deamon that handles lock tokens the svnsync clients can use to synchronise, and which can purge stale locks. Much like rpc.lockd in NFS. > > For now, users cannot assume that svnsync will handle concurrent > > syncs, and need to take care of synchronising sync jobs themselves. > > I really want a way to turn off svnsync's current locking, so I can > use file locking instead (svn_io_file_lock2() or similar). This > keeps all the locking on a single machine, so I don't have to worry > about network failures. Even if a process dies unexpectedly, the > OS will automatically release file locks. > It would also be useful if svnsync had file locking built in. You can use tools like lockf or lockfile (part of procmail) for that. $ flock /tmp/svnsync.lock svnsync sync file://... But it only works if the synsync processes run on the host where the target repository is located (i.e. you have to run synsync pulls from a cronjob on the mirror, rather than triggering svnsync pushes from a post-commit hook). > Would it be reasonable to add a "--local-lock-file FILENAME" option > to svnsync, which would turn off the current locking and use file > locking instead? If so, I can work on a patch to do this. I think we need an approach that also works over the network. > (As an alternative, if you don't like having the locking built in, > how about a "--no-remote-lock" option?) You know where the code is, so for now, if you don't want it, you can wrap it in #if 0 :) But seriously, I guess we might as well remove the current locking code altogether and tell people that svnsync does no locking until we come up with a good solution. Stefan