[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts WC API - making it private; adm_access

From: Neels J. Hofmeyr <neels_at_elego.de>
Date: Wed, 12 Nov 2008 02:37:53 +0100

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.


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


Received on 2008-11-12 02:38:43 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.