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

RE: Trouble replacing adm_access in libsvn_client/merge.c (merge_file_changed)

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Tue, 25 Aug 2009 15:23:10 +0200

> -----Original Message-----
> From: Daniel Näslund [mailto:daniel_at_longitudo.com]
> Sent: dinsdag 25 augustus 2009 15:13
> To: dev_at_subversion.tigris.org
> Subject: Re: Trouble replacing adm_access in libsvn_client/merge.c
> (merge_file_changed)
>
> On Tue, Aug 25, 2009 at 02:52:53PM +0200, Hyrum K. Wright wrote:
> > On Aug 25, 2009, at 2:46 PM, Bert Huijben wrote:
>
> > > Yes, please add a svn_wc__adm_retrieve_(with/via/...?)_context()
> > > helper.
> > >
> > > I think that would be a useful helper in more places of
> > > libsvn_client, until libsvn_wc accepts wc_ctx, abspath everywhere.
> >
> > Note that we already have a svn_wc__adm_retrieve_internal2() API
> which
> > accepts an wc_db and abspath, and just fetches the baton from the
> db's
> > set of cached batons. Perhaps this might be of some use. One catch
> > here is that the *type* of the baton needs to be correct. In other
> > words, we should return a cached read baton, when the caller asks for
> > a read/write baton. (I tried making *all* batons read/write at one
> > point, but that introduces problems of it's own, believe it or not.)
>
> I was planning on just wrapping svn_wc__adm_retrieve_internal2() and
> feed it with the db of the wc_ctx. I thought that I could just get me
> the existing baton. For my purpose (those darn wc_diff_callbacks) I
> know
> what kind of lock was set by the caller. Hrm, I'm reading a course in
> design
> pattern and that doesn't sound like louse coupling to me.
>
> Can one path have multiple batons, i.e. one read baton and another
> write
> baton? I thought that there would only be one?

In the old code there can be more, but there should be just one. (The wc_db
+- has a hashtable mapping absolute paths to access batons)

Most svn_client_*() function calls start by opening an access baton for
writing for the part of the working copy they are interested in (depth
infinity for most recursive calls) and retrieving this baton via the context
will usually work just fine.

        Bert
>
> > What *I* want to see, and I don't know if we have it or not, is
> > something which I could call to "go get me an access baton for PATH,
> > whether you fetch the cached one, or whether you open a new one, I
> > don't care." Maybe we have that already, or maybe it's just a pipe
> > dream.
>
> I haven't found one.

svn_wc_adm_try_probe...() does about that, but it is not very friendly,
because other code has to switch to the same kind of calls then. (It
sometimes receives an access baton, sometimes not.. and access batons are
closed everywhere via pool cleanup).

I think moving to lock once before the major operation will make the
transfer to WC-NG easier. (I don't think we should introduce new access
batons just to make a few places easier).

        Bert

(Mostly working on things beside subversion and on the adm_crawler)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2387074
Received on 2009-08-26 23:49:19 CEST

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