On Tue, 26 Jul 2005, Alexander Thomas wrote:
> On Tue, 2005-07-26 at 23:59 +0200, Peter N. Lundblad wrote:
>
> Thanks for explaining the problem to the utmost satisfaction.
>
> > > > Option 2: Just don't bother to create svn_dirent2_t. Instead, just
> > > > rev svn_client_ls() could return a new "svn_client_dirent_t"
> > > > structure which contains the lock_t. (Or return the hash of locks to
> > > > the caller.)
> > > >
> > I actually prefer this solution (creating svn_client_dirent_t), since it
> > will create a new struct with the lock field always valid where it is
> > used. kfogel pointed out that this will leave us with a deprecated struct
> > when (if) we eventually revise svn_dirent_t. I don't think that's a big
> > problem; we already have lots of deprecated stuff.
> >
> If we are so sure of deprecating the new struct svn_client_dirent_t in
> feature date, why we creating it now. I might be wrong here still, what
> you feel about creating new function as svn_client_ls_with_lock () or
> svn_client_ls3 () returning both dirent_t hash and lock_t hash to the
> caller ?
>
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.
I hope others can live with this design too.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 27 22:59:45 2005