Can you resend with a log message, as described in our hacking.html
file?
(You can also run 'svn log' on the svn repository for 16,000 examples.)
On Sep 11, 2005, at 7:39 PM, Christopher Ness wrote:
> Hi All,
>
> This is my first crack at this issue. I've still got some problems.
>
> I'm going to review the parts of the patch I'm having trouble with,
> and
> have attached the complete patch for your perusal.
>
> I have also attached my test repository with the dump file.
> r1:2 is a replace of trunk/file.c
>
> Much thanks to `eh' on the IRC channel for his patience and guidance!
>
>
> @@ -50,6 +50,12 @@
> #include "lock.h"
> #include "props.h"
>
> +#define ADD "add"
> +#define DEL "del"
> +#define NESS_DEBUG 1
> +
> +const char * hash_get_set (apr_hash_t * ht, const void * key,
> + const char * add_or_del);
>
> Not sure what to do with my own private functions and defines.
> HACKING
> seems to be quiet on the matter. But I haven't seen any other
> functions
> in code - so does everything go into header files?
>
> Comment out the NESS_DEBUG define to stop the verbose trace lines.
>
> @@ -995,18 +1013,6 @@
> logfile_path, parent_path, pool));
> *log_number = 0;
>
> - /* The passed-in `path' is relative to the anchor of the edit,
> so if
> - * the operation was invoked on something other than ".", then
> - * `path' will be wrong for purposes of notification. However, we
> - * can always count on the parent_path being the parent of
> base_name,
> - * so we just join them together to get a good notification path.
> - */
> - if (eb->notify_func)
> - (*eb->notify_func)
> - (eb->notify_baton,
> - svn_wc_create_notify (svn_path_join (parent_path,
> base_name, pool),
> - svn_wc_notify_update_delete, pool),
> pool);
>
> Looking at this comment now I didn't use the svn_path_join() method
> like
> it warns against. Does this comment still apply today as it did in
> 2002?
>
> Now to the part that is getting me.
>
> + for (hi = apr_hash_first(db->pool, db->deleted_targets); hi; hi
> = apr_hash_next(hi))
> + {
> +#ifdef NESS_DEBUG
> + i++;
> +#endif
> + const void *vkey;
> + void *vval;
> + const char *key;
> + const svn_string_t *val;
> +
> + apr_hash_this(hi, &vkey, NULL, &vval);
> + key = vkey;
> + val = vval;
> +#ifdef NESS_DEBUG
> + fprintf(stderr, "[%d] hash key = '%s' was found with val = '%
> s'\n", i, key, (char *)val);
> +#endif
> + if ((char*)val == DEL && db->edit_baton->notify_func)
> + {
> + (*db->edit_baton->notify_func)
> + (db->edit_baton->notify_baton,
> + svn_wc_create_notify (key,
> + svn_wc_notify_update_delete, pool),
> pool);
> + }
> + }
>
> I'm thinking the const char * is killing me. In my testing it is
> giving
> the same entries (yes, I know what the constant keyword means), and
> not
> seeming to loop though the hash table as I expected for the key
> values.
> But this is what the function arp_hash_this() returns for the key!
>
> How can I get around the const void * above and loop through the hash
> table with proper keys returned? This seems rather common to me to
> want
> to get back the keys you entered.
>
> The next loop is bigger and uglier than needed but it tries to delete
> the entries in the loop and probably fails to do so since the keys do
> not appear to be updating.
>
>
>
> Comments and hints on beating this apr_hash_this() problem please.
>
> I'm helping a friend build a shed tomorrow so I won't be around for
> most
> of the day.
>
> Cheers,
> Chris
> --
> PGP Public Key: http://www.nesser.org/pgp-key/
> 20:05:22 up 5:43, 3 users, load average: 0.53, 0.55, 0.33
>
> <ness-issue571-first-attempt.patch>
> <test-571.repos.gz>
>
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 12 04:43:21 2005