branch tree-conflicts-notify

Hey guys,

I'm quite glad that we're all moving in the same direction, but by now I'm
thoroughly confused as to what is being done by whom, and what I should be
doing next.

I updated my branch wc but don't see most of the changes you talked about.
Are you committing on trunk? Steve, I see you updated the branch to trunk.
Are you trying to confuse me? ;)

Maybe it would be good if we keep the others updated on what we were doing,
as in post unfinished patches so that we don't do the exact same things in
parallel. Btw, have you guys finished the other stuff you took?

So, I'll take a look at merge notification, then. I'm afraid to change
either of svn_wc_conflicted_p2() or update notification, because I fear you
guys have patches floating for it already.

Am I being cranky? ;)

~Neels

Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
>>>
>>> Hmm. I've just had a look. I would want the new svn_wc_conflicted_p2()
>>> to be rather different from the old ..._p().
>>>
>>> (1) It needs to take an adm_access. It should take this INSTEAD of an
>>> "entry", as it can easily get the entry for itself. There is no need to
>>> make the caller do this extra step. The rules for adm_access should
>>> probably be, "If there is an open adm access baton for path's parent,
>>> then adm_access must be in a set that includes it; and if there is an
>>> open adm access baton for path, then adm_access must be in a set that
>>> includes it." or something like that.
>>>
>>> (2) While we're there, we should make all of the output parameters
>>> optional.
>>>
>>> (3) The path need not be the path of a version-controlled object.
>>>
>>> (4) The old function's path parameter is called "dir_path". Not sure
>>> why. The new one should be called just "path" as it applies to any node
>>> kind.
>>
>> (4) OK, I see why it's called "dir_path": (name-of-a-directory,
>> entry-from-the-directory) is one way of identifying an item in the WC.
>> We need to change (1) and (4) together, so that the new interface is:
>> (name-of-an-item, adm-access-for-the-item). This achieves (3).
>>
>>
>>> The old function looks for files on disk as well as what the "entry"
>>> says to determine whether there are text and prop conflicts. I don't
>>> propose changing that now, even though we have no equivalent behaviour
>>> for tree conflicts.
>>>
>>> - Julian
>>
>
> Hi Julian,
>
> Sorry I missed your last email. As it turns out, my new function was
> almost exactly like your plan, except I hadn't gotten rid of the entry
> arg yet. Now I hope I'll get full marks:
>
> [[[
> /** Given a @a path in a dir under version control, decide if it is in
> * state of conflict; return the answers in @a *text_conflicted_p, @a
> * *prop_conflicted_p, and @a *tree_conflicted_p. If one or two of the
> * answers are uninteresting, simply pass NULL pointers.
> *
> * If @path is unversioned or does not exist, @a *text_conflicted_p and
> * @a *prop_conflicted_p will be @c FALSE.
> *
> * @a adm_access is the admin access baton of the parent directory.
> *
> * If the @a path has a corresponding text conflict file (with suffix
> * .mine, .theirs, etc.) that cannot be found, assume that the text
> * conflict has been resolved by the user and return @c FALSE in @a
> * *text_conflicted_p.
> *
> * Similarly, if a property conflicts file (.prej suffix) exists, but
> * it cannot be found, assume that the property conflicts have been
> * resolved by the user and return @c FALSE in @a *prop_conflicted_p.
> *
> * @a *tree_conflicted_p can't be auto-resolved in this fashion. An
> * explicit `resolved' is needed.
> *
> * @since New in 1.6.
> */
> svn_error_t *
> svn_wc_conflicted_p2(svn_boolean_t *text_conflicted_p,
> svn_boolean_t *prop_conflicted_p,
> svn_boolean_t *tree_conflicted_p,
> const char *path,
> svn_wc_adm_access_t *adm_access,
> apr_pool_t *pool);
> ]]]
>
> Cheers,
> Steve

-- 
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