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

Re: svn info --recursive isn't reporting tree-conflict-only nodes

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Tue, 3 May 2011 10:49:17 -0500

On Tue, May 3, 2011 at 10:19 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Tue, 2011-05-03 at 14:36 +0100, Philip Martin wrote:
>> Julian Foad <julian.foad_at_wandisco.com> writes:
>> > I found a bug in "svn info -R": it doesn't report a node that has a tree
>> > conflict but otherwise is nonexistent, except if this node is the root
>> > node of the requested target path.
>> I think that's an actual-only node.  See
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3779
>> which says that we need to ensure that commands behave sensibly on
>> actual-only nodes.
> Yes.
> The 'info' code uses svn_wc__internal_walk_children(), and makes a
> special case of checking for a tree conflict on the target node if that
> walk function returns a NOT FOUND error.  But 'info' doesn't check for
> tree conflicts on other unvisited leaf nodes that may exist as
> actual-only nodes.
> One way or another, 'info' is going to have to walk a tree of nodes that
> includes actual-only nodes.  It could either do this itself or we could
> have a walker function that does that.  It's logically re-usable
> functionality (even if 'info' is currently the only user) so we should
> have some kind of walker function that does that.  So I'll look at
> adding this functionality into svn_wc__internal_walk_children().

That's my "gut feeling" as well. ACTUAL-only children are still
children (in some sense), and should be included in the set of paths
returned by a walk of the children.

I seem to recall attempting to include tree conflict victims in the
set of walked children a few months ago, but the state of the code at
that time did not make it very practical. I think times have since

Received on 2011-05-03 17:49:47 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.