Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>> On Thu, 2008-10-23 at 13:31 +0200, Neels J Hofmeyr wrote:
>>> Stephen Butler wrote:
>>> > Quoting "Neels J. Hofmeyr" <neels_at_elego.de>:
>> But that doesn't enable us to read back the conflict state immediately
>> after loggy-writing it, does it?
> No. We need check_tree_conflict() to tell us whether it found a conflict.
> Then we'll modify the output, in callbacks that print output immediately.
> For open_file() and open_directory(), we'll stash the tree_conflicted
> boolean in the file or dir baton, for use when the item's output is
> printed upon closing it.
Ah, I missed that one. Nice.
>>> > I suggest we un-deprecate the original svn_wc_conflicted_p() and use
>>> > it for reading text and prop conflict state only. And use the
>>> > svn_wc_get_tree_conflict() to read tree conflict state.
> Any arguments against this?
Yes, semi. I agree with taking away the has_tree_conflicted_children_p
parameter, but I would endorse keeping the tree_conflicted_p. For the simple
reason that anyone outside of the callbacks functions calls
svn_wc_conflicted_p.*() to see whether the node has a conflict that should
prevent it from changing something. And I suddenly grasp this: Even in the
callbacks, tree_conflicted_p is useful to report any tree-conflicts that
have been around before the current operation was launched. So we need both
the return value of check_tree_conflict() *and* tree_conflicted_p from
svn_wc_conflicted_p2(), right? (Unless check_tree_conflict() already covers
persistence of older conflicts, and then this point still holds true for use
outside the callbacks.)
Neels Hofmeyr -- elego Software Solutions GmbH
Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23458696 mobile: +49 177 2345869 fax: +49 30 23458695
http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelsreg: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Received on 2008-10-23 15:24:37 CEST