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

Re: Using svn_wc_walk_entries for recursive propget etc.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-14 15:39:58 CET

Julian Foad <julianfoad@btopenworld.com> writes:

> While trying to make all operations proceed in sorted order, I
> noticed that recursive propget, proplist and propset all do their
> own recursion, and should probably make use of "svn_wc_walk_entries"
> to do it for them (for BASE and WC).
> The attached _unfinished_ patch does this for propget and proplist.
> It works about as well as the existing code, but I'd like to know if
> I'm on the right track before I finish it. Questions:
> 1. Is it OK to use, in each directory, the adm. access baton for the
> top of the tree, or should I be getting an access baton for each
> directory individually as the original code did? I don't know the
> pros and cons of this.

As a general sentiment, the code is often inconsistent here. Some
functions let you pass the top-level ADM access baton, and a path.
Some make you pass the individual item's baton, and they simply ask
that baton for the path it represents.

> 2. The remote (repository) versions of these functions are also
> doing their own recursion. Is there a better or equivalent way in
> which those should be written?

And what functions are those?

> 3. When I am walking the WC, I want to omit entries that are
> scheduled for deletion, and svn_wc_walk_entries has a parameter to
> select this behaviour. When I am walking BASE, I want to omit
> entries that are scheduled for addition. There is no option for
> this. I will have to examine the scheduling of each item (and I
> have not done this yet). Perhaps this inconsistency is justified on
> the basis of "most common usage", as presumably more code paths look
> at the WC than at BASE, but I'm not sure. Just provoking thought.

svn_wc_walk_entries() has room to grow -- it makes no claim to
completeness. If you think a new "mode" for skipping added things, so
be it.

> 4. The existing code omits scheduled-delete items even if it is
> operating on BASE, which is wrong. I might commit this new
> regression test first, in XFAIL state, and then, in a second commit,
> change the tree-walking code and change the test to normal.

Good plan.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 14 15:43:07 2003

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.