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?
> 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
I haven't found one.
Received on 2009-08-26 23:49:50 CEST