Julian Foad <email@example.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
> 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Nov 14 15:43:07 2003