On Thu, Jul 11, 2002 at 02:10:44PM -0500, philip@tigris.org wrote:
> Author: philip
> Date: Thu, 11 Jul 2002 14:10:22 -0500
> New Revision: 2470
>
> Modified:
> trunk/subversion/include/svn_wc.h
> trunk/subversion/libsvn_client/client.h
> trunk/subversion/libsvn_client/commit.c
> trunk/subversion/libsvn_client/copy.c
> trunk/subversion/libsvn_client/externals.c
> trunk/subversion/libsvn_wc/adm_files.c
> trunk/subversion/libsvn_wc/adm_files.h
> trunk/subversion/libsvn_wc/adm_ops.c
> trunk/subversion/libsvn_wc/lock.c
> trunk/subversion/libsvn_wc/log.c
> trunk/subversion/libsvn_wc/log.h
> trunk/subversion/libsvn_wc/props.c
> trunk/subversion/libsvn_wc/update_editor.c
> trunk/subversion/libsvn_wc/wc.h
> Log:
> Continue issue #749. Pass the access baton into more functions, mainly
> connected with running log files. The locks acquired before starting
> a commit are now held until the post-commit processing is complete.
Okay, so here's the crux of the caching matter.
We need to be passing the access baton into the svn_wc_entry
functions. So, does it make sense to create a "cached" variant of
svn_wc_entry that can take in the access baton (basically what my
patch does)? We can then switch places over to use the cache where
we have access to the baton.
Or, does it make sense to try and modify every usage of svn_wc_entry
to require an access baton? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 11 21:35:22 2002