[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Patch] Issue #2291 - 'svn ls -v' should return locking information - V5

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-07-27 23:39:09 CEST

On Jul 27, 2005, at 3:58 PM, Peter N. Lundblad wrote:

> Yesterday I thought this wasn't good, since when we make svn_client_ls
> streamy (there's an issue for that, too), this wouldn't be good, since
> we'd need to pass the lock with the rest of the dirent. Now that I
> think
> of it again, I realize that we can take care of that when we do the
> streaminess work.
> So, I'm +1 for the above.
> But, please make the hash keys in the lock hash relative paths so
> they're
> the same as the keys in the dirents hash, and I suggest filtering
> the hash
> in the non-recursive case (so we don't return all locks under the path
> with infinite depth). Also, since you're adding another parameter
> anyway,
> I suggest allowing it to be NULL, making it possible to avoid the
> possibly
> expensive get_locks call (in the non-verbose case in the cmdline
> client,
> for example). I think this optimization is actually a good idea, since
> else, a non-recursive, non-verbose ls command in a repository with
> many
> locks could be unreasonably slow.

Alexander: kfogel and I are in agreement with what Peter is saying.
I think it's safe to do another patch now. :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 27 23:42:08 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.