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

Re: svn commit: r920875 - in /subversion/trunk/subversion: include/svn_wc.h libsvn_client/commit.c libsvn_wc/adm_ops.c

From: Neels J Hofmeyr <neels_at_elego.de>
Date: Thu, 11 Mar 2010 11:18:23 +0100

Greg Stein wrote:
> On Tue, Mar 9, 2010 at 08:53, <philip_at_apache.org> wrote:
>> ...
>> +++ subversion/trunk/subversion/include/svn_wc.h Tue Mar 9 13:53:38 2010
>> @@ -4729,14 +4729,14 @@ svn_wc_committed_queue_create(apr_pool_t
>>
>> /**
>> * Queue committed items to be processed later by
>> - * svn_wc_process_committed_queue().
>> + * svn_wc_process_committed_queue2().
>> *
>> - * All pointer data passed to this function (@a path, @a adm_access,
>> - * @a wcprop_changes and @a checksum) should remain valid until the queue
>> - * has been processed by svn_wc_process_committed_queue().
>> + * All pointer data passed to this function (@a path, @a wcprop_changes
>> + * and @a checksum) should remain valid until the queue
>> + * has been processed by svn_wc_process_committed_queue2().
>> *
>> * Record in @a queue that @a path will need to be bumped after a commit
>> - * succeeds. @a adm_access must hold a write lock appropriate for @a path.
>> + * succeeds.
>> *
>> * If non-NULL, @a wcprop_changes is an array of <tt>svn_prop_t *</tt>
>> * changes to wc properties; if an #svn_prop_t->value is NULL, then
>> @@ -4763,7 +4763,25 @@ svn_wc_committed_queue_create(apr_pool_t
>> * it will bump ALL nodes under the directory, regardless of their
>> * actual inclusion in the new revision.
>> *
>> + * @since New in 1.7.
>> + */
>> +svn_error_t *
>> +svn_wc_queue_committed3(svn_wc_committed_queue_t *queue,
>> + const char *path,
>> + svn_boolean_t recurse,
>> + const apr_array_header_t *wcprop_changes,
>> + svn_boolean_t remove_lock,
>> + svn_boolean_t remove_changelist,
>> + const svn_checksum_t *checksum,
>> + apr_pool_t *scratch_pool);
>
> Note: internally, I renamed those booleans to match their command-line
> flags. no_unlock and keep_changelist. Those are *inverted* from the
> above semantics, but I think they're inherently more descriptive since
> they correspond to actual user operations. Since you are revising the
> function, we could take this opportunity to rename the flags and
> invert their meaning.
>
> My only caution here, would be somebody adding a "3" to their function
> call and dropping the access baton. And NOT stopping to invert the
> meaning.
>
> Thoughts?

We could also change the argument order to get compile time errors.

~Neels

Received on 2010-03-11 11:19:08 CET

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.