On Tue, 26 Jul 2005, Alexander Thomas wrote:
> > different route here. kfogel, lundblad and I had a conversation, and
> > we think that this patch puts us in a bad "halfway" place. This
> > patch deprecates svn_dirent_t, but not fully. It's still being used
> > in other places. We think that we should either do it all the way,
> > or not do it.
> >
> > Option 1: *Fully* deprecate svn_dirent_t. That means stop using it
> > everywhere. It means having to rev all the public libsvn_client and
> > libsvn_ra APIs that make use of it. Quite a lot of work.
> >
The big problem with this approach is that we'll be lying, or at least
inconsistent. If we create svn_dirent2_t with a new lock field,
svn_ra_get_dir can't in an efficient way fill that field with information
(because of infinite depth of get_locks). svn_ra_stat and svn_repos_stat
could get the lock and svn_client_ls would get it as well. I dislike this
inconsistency.
> > 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.
> Making changes in svn_client_ls() to accommodate lock_t, feels like
> hackish. MHO is to move this to ra_get_dir() like in version #4 and
Aggreed that it is hackish. We'd like the lock to be a "first class
citizen" among other entryprops (last author, commit time etc.)
> return a hash containing both dirent_t and lock_t. Yes it need lot
> more work, but hope will be more efficient.
>
This means get_locks with depth=1 support. As I understand it, the BDB
locking implementation makes that hard to do efficiently. I might be wrong
here.
> > Alexander: many apologies for bouncing the strategy of your
patch
> > back and forth. You are a man of infinite patience. :-) Let's
> > discuss a bit more before you write another iteration of this patch.
>
> No need for many apologies, one will do :). I am still in subversion
> LEARNING MODE, so never mind.
>
The problem is that we currently give you very good advice, becuase we
aren't sure how to handle this situation. Technically, I think we're in
total agreement, it is just a question of least ugly API design:-(
Regards,
//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 00:00:18 2005