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

Re: Problem with svn_wc_process_committed

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-07-12 15:55:14 CEST

Justin Erenkrantz <jerenkrantz@apache.org> writes:

> Oops. Either the locked_dirs hash needs to get passed to
> svn_wc_process_committed or we need to go back to unlocking the
> dirs before svn_wc_process_committed is called. -- justin

Unlocking and then relocking doesn't look right to me, not only will
it kill any cacheing, but dropping locks in what should be an atomic
process is a bit odd.

I have been thinking about putting the svn_wc_adm_access_t structures
into a hierarchy, with parents keeping a list of children, and
children a pointer to the parent. Then the initial commit processing
could lock the entire directory tree being committed before starting
the commit, and svn_wc_process_committed would not need to take out
any new locks. This might help with the cacheing as well, giving
parents access to children and vice-versa.

   svn_error_t *
   svn_wc_adm_open(svn_wc_adm_access_t **adm_access,
                   svn_wc_adm_access_t *parent_access,
                   const char *path,
                   svn_boolean_t write_lock,
                   apr_pool_t *pool);

Where parent_access can be NULL. When parent_access is not NULL the
first svn_wc_adm_open for a given path stores the new child baton in
an internal hash. Subsequent calls for the same path return the baton
out of the cache.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 12 15:55:50 2002

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.