You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/11/24 18:22:51 UTC
Re: svn commit: r12012 - in trunk/subversion: libsvn_client libsvn_wc tests/clients/cmdline
philip@tigris.org writes:
> --- trunk/subversion/libsvn_wc/log.c (original)
> +++ trunk/subversion/libsvn_wc/log.c Tue Nov 23 18:37:33 2004
> @@ -1480,29 +1481,45 @@
> SVN_ERR (svn_wc__adm_steal_write_lock (&adm_access, optional_adm_access,
> path, pool));
>
> - /* Recurse on versioned subdirs first, oddly enough. */
> + /* Recurse on versioned elements first, oddly enough. */
> SVN_ERR (svn_wc_entries_read (&entries, adm_access, FALSE, pool));
> -
> + subpool = svn_pool_create (pool);
> for (hi = apr_hash_first (pool, entries); hi; hi = apr_hash_next (hi))
> {
> const void *key;
> void *val;
> const svn_wc_entry_t *entry;
> + const char *entry_path;
>
> + svn_pool_clear (subpool);
> apr_hash_this (hi, &key, NULL, &val);
> entry = val;
> + entry_path = svn_path_join (path, key, subpool);
>
> - if ((entry->kind == svn_node_dir)
> - && (strcmp (key, SVN_WC_ENTRY_THIS_DIR) != 0))
> + if (entry->kind == svn_node_dir
> + && strcmp (key, SVN_WC_ENTRY_THIS_DIR) != 0)
> {
> - /* Recurse */
> - const char *subdir = svn_path_join (path, key, pool);
> - SVN_ERR (svn_io_check_path (subdir, &kind, pool));
> + /* Sub-directories */
> + SVN_ERR (svn_io_check_path (entry_path, &kind, subpool));
> if (kind == svn_node_dir)
> - SVN_ERR (svn_wc_cleanup (subdir, adm_access, diff3_cmd,
> + /* ### I'd like to pass subpool and close the batons as we go
> + ### but we probably need 2.0 for such a behaviour change */
> + SVN_ERR (svn_wc_cleanup (entry_path, adm_access, diff3_cmd,
> cancel_func, cancel_baton, pool));
What happens if we pass subpool right now? If we're recursing
depth-first, and we close batons from the bottom up, how is that a
visible behavior change?
(Not arguing, just not understanding something.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12012 - in trunk/subversion: libsvn_client libsvn_wc tests/clients/cmdline
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> > opened being returned. So aren't we free to change this aspect of its
> > behavior, especially since it wasn't strictly documented anyway?
>
> I don't know, are we? It's not Subversion that will have problems but
> other projects built on Subversion.
Since the behavior was not documented, it was not a promise. It
depends what your definition of "is" is. :-)
I mean, I could see us taking a different stance with some other
aspect of some other function. But I highly doubt that anyone even
knew about, let alone was taking advantage of, this undocumented
functionality of svn_wc_cleanup(). So you could give yourself a
little more freedom, IMHO...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12012 - in trunk/subversion: libsvn_client
libsvn_wc tests/clients/cmdline
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>> At present if an baton is passed to svn_wc_cleanup all the access
>> batons opened are returned (yes, the function suffers from incomplete
>> documentation in svn_wc.h). If svn_wc_cleanup didn't have to return
>> the batons then we could close them as we go and make better use of
>> the subpool. svn_wc_cleanup2 isn't really an answer, since we would
>> still have to provide svn_wc_cleanup.
>
> As far as I can tell, no caller of svn_wc_cleanup(), except possibly
> for svn_wc_cleanup() itself, is depending on all the access batons
Correct as far as Subversion is concerned, and svn_wc_cleanup doesn't
need them.
> opened being returned. So aren't we free to change this aspect of its
> behavior, especially since it wasn't strictly documented anyway?
I don't know, are we? It's not Subversion that will have problems but
other projects built on Subversion.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12012 - in trunk/subversion: libsvn_client libsvn_wc tests/clients/cmdline
Posted by kf...@collab.net.
Philip Martin <ph...@codematters.co.uk> writes:
> At present if an baton is passed to svn_wc_cleanup all the access
> batons opened are returned (yes, the function suffers from incomplete
> documentation in svn_wc.h). If svn_wc_cleanup didn't have to return
> the batons then we could close them as we go and make better use of
> the subpool. svn_wc_cleanup2 isn't really an answer, since we would
> still have to provide svn_wc_cleanup.
As far as I can tell, no caller of svn_wc_cleanup(), except possibly
for svn_wc_cleanup() itself, is depending on all the access batons
opened being returned. So aren't we free to change this aspect of its
behavior, especially since it wasn't strictly documented anyway?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r12012 - in trunk/subversion: libsvn_client
libsvn_wc tests/clients/cmdline
Posted by Philip Martin <ph...@codematters.co.uk>.
kfogel@collab.net writes:
>> - SVN_ERR (svn_wc_cleanup (subdir, adm_access, diff3_cmd,
>> + /* ### I'd like to pass subpool and close the batons as we go
>> + ### but we probably need 2.0 for such a behaviour change */
>> + SVN_ERR (svn_wc_cleanup (entry_path, adm_access, diff3_cmd,
>> cancel_func, cancel_baton, pool));
>
> What happens if we pass subpool right now? If we're recursing
> depth-first, and we close batons from the bottom up, how is that a
> visible behavior change?
>
> (Not arguing, just not understanding something.)
At present if an baton is passed to svn_wc_cleanup all the access
batons opened are returned (yes, the function suffers from incomplete
documentation in svn_wc.h). If svn_wc_cleanup didn't have to return
the batons then we could close them as we go and make better use of
the subpool. svn_wc_cleanup2 isn't really an answer, since we would
still have to provide svn_wc_cleanup.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org