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

Re: Adding svn_wc__db_status_omitted

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 15 Jun 2010 14:40:17 -0400

On Tue, Jun 15, 2010 at 07:20, Philip Martin <philip.martin_at_wandisco.com> wrote:
> The new SVN_EXPERIMENTAL_COPY code does a couple of new things:
>
> - when copying a directory it uses the "insert a complete directory
>  with incomplete children" approach.
>
> - when copying an excluded node (as the child of a copied parent) it
>  puts the excluded node in the WORKING_NODE table rather than the
>  BASE_NODE table.
>
> At present I'm using svn_wc__db_status_incomplete and
> svn_wc__db_status_excluded for these sorts of working node, but this
> causes problems.  The main one is that when svn_wc__db_read_info
> returns one of these as a status value the caller cannot easily
> determine if it represents a base node or a working node.
>
> We could fix this by adding new status values (I was thinking of using
> svn_wc__db_status_omitted for copies of svn_wc__db_status_excluded)
> but an alternative would be to change/extend the base_shadowed flag to
> something that allowed the caller to determine the state.
>
> Anyone have any opinions?

I think that I'd prefer the latter: replace base_shadowed with
something that describes the situation better. That could be a pair of
booleans (have_base and have_work), or a single integer with flags
(harder to use). Returning have_act is potentially arguable, but I'd
start with "no" since very little of the output is dependent upon that
value (and is thus relatively easy to tell when ACTUAL exists).

Also note: we should get rid of the text_mod parameter. If you do that
at the same time, then the number of arguments won't change, and the
vast majority of calls will not need to change. You'll only need to do
it where props_mod or base_shadowed is requested.

Cheers,
-g
Received on 2010-06-15 20:40:57 CEST

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.