Re: Performance of "svn lock *"

Bert Huijben <bert_at_qqmail.nl> writes:

> All those options work, but you could also just follow the Ra code and
> implement a callback with the result. The Ra layers can then batch or
> stream the result as they wish.

Reusing the RA design is worth considering. The interaction between the
repos hooks and FS write-lock makes it bit more difficult. This new FS
API will have a corresponding repos API that runs pre-lock and
post-lock. The repos layer would run all pre-locks before invoking FS
and the FS callback would invoke the repos callback. The repos callback
would run the post-lock hooks but we don't want to do that while holding
the FS write-lock. So the FS callbacks have to happen after the
write-lock is released.

   svn_repos_lock(paths, server_callback)
     for path in paths:
       run pre-lock
     svn_fs_lock(paths, repos_callback)
       take write-lock
       for path in paths:
         create lock
       release write-lock
       for path in paths:
         callback-to-repos

   repos_callback
     if lock
       run post-lock
     callback-to-server

   server_callback
     ...
   

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*