> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: woensdag 3 februari 2010 12:30
> To: Bert Huijben
> Cc: 'Stefan Sperling'; 'Bert Huijben'; 'Subversion Development'
> Subject: RE: two questions (and a proposed patch) regarding svn:ignore
>
> Bert Huijben wrote:
> > > -----Original Message-----
> > > From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> > > While we're revving it, consider this API design point. We pass the list
> > > of global ignores in to the function through the CTX parameter. It seems
> > > stupid to have an additional parameter that says whether to ignore the
> > > global ignores. Instead, the caller should set
> > > CTX->config['config:miscellany:global-ignores'] to empty before calling
> > > this function.
> > >
> > > Makes sense?
> >
> > >From 'svn' it makes sense to move the setting to the configuration as
> > 'svn' use a new 'svn_client_ctx_t' for every command.
> >
> > But, in several other clients the svn_client_ctx_t is a long living
> > object. (This is becoming more useful in WC-NG as it will keep the
> > handle to the wc.db instance open for you over multiple commands).
> >
> > This would require setting the setting before executing the command
> > and then resetting it later in the compatibility wrapper (and in other
> > libraries that don't want to change their api incompatible).
>
> Yes, it would. I nearly wrote that out in my original email. Do you
> think that's so awkward that the API should continue to have a special
> flag for overriding that part of the config?
We duplicate a lot of these settings in more and more places.
I don't have a huge issue with it as I will probably add it to my wrapper library and be done with it. (All functions in my wrapper have the required arguments as direct function argument and all the rest on a command specific args object that can be extended without breaking the ABI).
But it also makes us update a hashtable in a +- global pool for setting and resetting and I don't know how that influences memory usage of the hashtable and the data stored inside.
(Another minor issue with this approach is that we usually only test our compatibility wrappers only once... and we won't know that we broke them until a third party client starts complaining. Keeping the wrappers simple reduces the number of possible errors)
Bert
Received on 2010-02-03 13:45:08 CET