[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-07-26 23:59:29 CEST

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

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