On Mar 14, 2005, at 9:56 PM, C. Michael Pilato wrote:
> "Brian W. Fitzpatrick" <fitz@collab.net> writes:
>
>>> Yeah, we're already assuming paths can't have newlines in them in
>>> other places (dumpfile format, for example), so it's not like it can
>>> really hurt to do it here.
>>
>> *nod*
>>
>> Before I start hacking up libsvn_repos, did anyone have any
>> implementation thoughts WRT this change? fs_wrap.c has
>> svn_repos_fs_lock, and it takes a single path in, calls the pre-lock
>> hooks, does the lock, and then calls the post-lock hook. Now I don't
>> see any unobtrusive way to call the post-lock hook here, but maybe I'm
>> missing something.
>>
>> Anyone?
>
> Actually, I had this same thought earlier today. I think the thing to
> do is to make svn_repos_fs_lock take multiple paths for input, then:
>
> for path in lock_paths:
> pre_lock_hook (path)
> svn_fs_lock (path)
> post_lock_hook (lock_paths)
>
> That way when our RA layers get smart enough to take multiple locks at
> a time, stuff just works.
Sure, but there's no way to do this without having the server side of
the ra_layers (svnserve, dav_svn) aggregate the locks somehow, and then
fire the list off to svn_repos_fs_lock, so we're multiplying our
problem by three. The only solution that I see here that isn't going
to introduce tons of hacquery into our codebase is to just mod the ra
layers to send a list of locks.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 15 05:14:51 2005