On Fri, Mar 12, 2010 at 04:31, Bert Huijben <b...@qqmail.nl> wrote:
>...
>> +++ subversion/trunk/subversion/libsvn_wc/revision_status.c Fri Mar 12
>...
>> + /* We need the excluded and absent paths when checking for sparse
>> + * checkouts. But only for that. To collect those we're walking all the
>> + * hidden nodes. */
>> + if (status == svn_wc__db_status_excluded
>> + || status == svn_wc__db_status_absent)
>> + {
>> + wb->result->sparse_checkout = TRUE;
>> + return SVN_NO_ERROR;
>> + }
>...
>
> Added files imply that there is some modification, so you can just set
> wb->result->modified to TRUE as an else clause.
That's a very good point. You could set ->modified whenever one of the
following are seen:
* status_added
* status_obstructed_add
* status_deleted
* status_obstructed_delete
>...
>> + if (! wb->result->modified)
>> + {
>> + svn_boolean_t text_mod;
>> + svn_boolean_t props_mod;
>>
>> + SVN_ERR(svn_wc__props_modified(&props_mod, wb->db,
>> local_abspath,
>> + scratch_pool));
>> +
>> + SVN_ERR(svn_wc__internal_text_modified_p(&text_mod, wb->db,
>> + local_abspath,
>> + FALSE,
>> + TRUE,
>> + scratch_pool));
>> + wb->result->modified |= (text_mod || props_mod);
>> + }
>
> With the risk of over optimizing: no need to perform a text check when you
> already see a property modification.
A text compare is *never* over optimizing. We want to avoid that
whenever possible.
And even besides that, there really isn't such a thing as
"over-optimizing" unless/until you obfuscate your source code to gain
a few cycles. That certainly isn't a danger here.
>...
Cheers,
-g
