On 11/28/2012 03:39 PM, Julian Foad wrote:
> @@ -2425,10 +2441,8 @@ merge_dir_added(svn_wc_notify_state_t *s
>> }
>> else
>> {
>> - const char *added_path = apr_pstrdup(merge_b->pool,
>> - local_abspath);
>> - apr_hash_set(merge_b->dry_run_added, added_path,
>> - APR_HASH_KEY_STRING, added_path);
>> + merge_b->dry_run_last_added_dir =
>> + apr_pstrdup(merge_b->pool, local_abspath);
>
> Oops -- no longer setting the hash here. Maybe use a macro or function to encapsulate both parts of the "registration".
Hrm... the original logic didn't add it to the hash here, either. I seem to
have made that additional apr_hash_set() accidentally in r1414810. You can
examine the sum of my changes to this file like so:
svn diff -r1414809:1414880 subversion/libsvn_client/merge.c
Doing so reveals that, in the end, I didn't actually changed the behavior in
this code section. And yet ... it does make me wonder if this is just some
latent bug waiting to be revealed. Certainly seems suspect.
Paul: have you any opinions here? To summarize, I'm wondering why, in
merge_dir_added(), in the switch that begins like so:
/* Switch on the on-disk state of this path */
switch (kind)
... the merged addition of a brand new directory earns that directory a
registration in both the dry_run_last_added_dir slot *and* the dry_run_added
hash, but a merged directory addition atop an unversioned or previously
deleted directory only winds up in dry_run_last_added_dir (and *not* the
dry_run_added hash). Any ideas?
>> }
>> if (state)
>> *state = svn_wc_notify_state_changed;
>> @@ -2467,6 +2481,9 @@ merge_dir_added(svn_wc_notify_state_t *s
>> }
>> break;
>> case svn_node_file:
>> + if (merge_b->dry_run)
>> + merge_b->dry_run_last_added_dir = NULL;
>
> Clearing that path is just an optimization, right? (Also below.)
As far as I can tell, yes. As above, I was merely restoring the behavior to
what it was before I started mucking with this code at all.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-11-29 02:27:59 CET