[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: Greg Stein <gstein_at_gmail.com>
Date: Thu, 13 Nov 2008 12:01:46 -0800

On Tue, Nov 11, 2008 at 7:15 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Nov 11, 2008 at 02:11:16PM +0000, Julian Foad wrote:
>...
>> * 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 :)

Access batons should disappear.

There will be a "context" for working with the WC, but it will be the
same context regardless of what directory (or even working copy!) that
you're talking about. You'll be able to record tree conflict on a
directory sitting under an unversioned directory.

Cheers,
-g

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-13 21:02:02 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.