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 ?
Regards,
-Alexander Thomas (AT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 27 07:37:16 2005