> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
>> On Thu, 2008-10-30 at 03:10 +0100, Neels J. Hofmeyr wrote:
>>>
>>> Stephen Butler wrote:
>>> > I propose that we remove the (new) tree_conflicted field from
>>> > svn_wc_notify_t, and add one or more notify-actions instead.
>>> > At the same time, change the notify() function in the client to
>>> > accept the new tree conflict notifications.
>>>
>>> Hey, that's actually a very good idea. I did this thinking that it
>>> would be
>>> good to have the usual notification alongside the conflict. But that is
>>> better solved with two new columns, as we discussed elsewhere.
As discussed, I have a patch simmering that, in svn_wc_notify_t, changes the
separate boolean TREE_CONFLICTED to a new svn_wc_notify_action_t called
svn_wc_notify_tree_conflicted.
I was hoping get it through quickly but it's bedtime now and it so far only
breaks everything. Haven't investigated thoroughly why that is so, yet.
>> There is already a "skip" notification defined:
>>
>> /** The type of action occurring. */
>> typedef enum svn_wc_notify_action_t
>> {
>> [...]
>> /** Skipping a path. */
>> svn_wc_notify_skip,
>> [...]
>>
>> Shouldn't we be using svn_wc_notify_skip as the "action occurring", and
>> set the "content_state" to "conflicted" or the "tree_conflicted" flag to
>> true to indicate that the reason is a conflict?
Hmm... I overlooked this. We don't have consensus on using the action to
notify a tree-conflict? Well, it doesn't make much difference really. But it
looks so far as if using the action fits pretty well and avoids some
conditions going true even though nothing happened as they expected
(comparing action to *_add to record something in a list about added items).
We could adapt the conditions and stuff, but it looks like most stuff
becomes simpler with a separate svn_wc_notify_tree_conflict action.
~Neels
Received on 2008-11-01 06:14:55 CET