On Jul 25, 2005, at 9:50 AM, Peter N. Lundblad wrote:
> On Mon, 25 Jul 2005, Alexander Thomas wrote:
>
>
>
>> Ben Collins-Sussman wrote:
>>
>>
>>
>>> Unfortunately, now we're faced with two choices, neither of which is
>>> optimal:
>>>
>>> * do a network request to get the dirents, then do N more network
>>> requests to fetch the lock on each dirent. This is what you're
>>> currently doing.
>>> or
>>> * do a network request to get the dirents, then do one more network
>>> request to fetch *all* locks below the path.
>>>
>>> After some discussion in the Chicago office, we all agree that's
>>> it's
>>> Less Evil to hold the entire hash of locks in memory than to make N
>>> network requests.
>>>
>>>
>>
>>
>> Here I am posting a new version of the patch which will hold the
>> entire
>> hash of locks in memory and does the rest.
>>
>>
>>
> I agree with using get_locks, but I don't think you should move it
> into
> the RA layer. The problem is that it will do an infinitely
> recursive lock
> traversal *per directory*. You can do svn_ra_get_locks in
> svn_client_ls
> instead. That way, you'll be able to get all locks only once.
>
>
Yes, this is exactly what I meant... to do the get_locks() call form
svn_client_ls(), so that it only needs to happen exactly once.
Alexander, can you try a version 5? :-)
> When/if we get a depth parameter on svn_fs_get_locks(), we can rev
> the RA
> API to provide the locks as well, making it streamy (as earlier
> discussed).
>
Agreed, that's a good longer-term plan.
>
> On another not, isn't it more useful to display the lock owner than
> the
> lock creation date with "svn ls -v".
>
I agree. When you discover a lock, I think the first thing you want
to know is who to call on the phone, not how old the lock is.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 18:06:42 2005