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.
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).
On another not, isn't it more useful to display the lock owner than the
lock creation date with "svn ls -v". Displaying everything in the XML is
great.
I hope to do a complete review when we've decided on the implementation.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 16:52:06 2005