On Mar 14, 2005, at 10:13 PM, Brian W. Fitzpatrick wrote:
>
> 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.
Oh wait. I've finally come to my senses and understood what Ben was
proposing: I'm just going to rev the API to the post-(un)lock hooks, so
for now, all they're going to get is an array containing 1 path that
was locked.
Move along... nothing to see here...
-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 06:10:50 2005