Stefan Sperling wrote:
> On Tue, Nov 11, 2008 at 02:11:16PM +0000, Julian Foad wrote:
>> These functions:
>>
>> svn_wc_get_tree_conflict()
>> svn_wc_add_tree_conflict()
>> svn_wc__del_tree_conflict()
>>
>> and
>>
>> svn_wc__loggy_add_tree_conflict()
>> svn_wc__loggy_del_tree_conflict()
>>
>> need some "consistifying".
>>
>>
>> * adm_access
>>
>> I have come up against difficulties with WC APIs that need to support
>> tree conflict (TC) victims. Such victims are not always versioned and so
>> do not always have the expected adm_access available. Also, the
>> implementation stores TCs in the parent dir's entry, so that's the place
>> we really need the baton for. Arguably it's more convenient for callers
>> if they don't have to know that and can supply the victim's adm_access
>> if they already have it. So we could choose either (the strict one)
>>
>> - "adm_access is the access baton for the parent dir of the victim.
>> (If there is no versioned parent, a tree conflict cannot be
>> represented.)"
>>
>> or (the lenient one):
>>
>> - "adm_access is an access baton in a set that contains an access
>> baton for the parent. (If there is no versioned parent, a tree conflict
>> cannot be represented.)"
>>
>> I'm going for the latter.
>
> Agreed.
Yes.
>
> I hope this parent directory business will go away with wc-ng,
> and be replaced by some magic mechanism that just works :)
Would sure be nice. I was thinking about storing tree-conflicts information
for a directory in its this-dir entry. But that would mean that a missing
directory cannot have a tree-conflict, right?
~Neels
Received on 2008-11-12 02:38:43 CET