The sparse-directories branch now passes 'make check' over all the RA
layers, including its new depth_tests.py. But the feature is not yet
done: there are a lot of tests still to write, and I'm positive that
many of them will expose problems. See
http://svn.collab.net/repos/svn/branches/sparse-directories/README.branch
...for a description of the feature and its current status.
However, I think it might be best to merge it to trunk as soon as it's
*no worse than* the feature it replaces, the "-N" option. -N has been
famously broken since it was born (see issue #695); -N checkouts
result in working copies of limited and unpredictable functionality.
On the branch, 'svn co -N' now maps to 'svn co --depth=files', and we
will soon be at the point where the working copies produced from that
are at least as useable as the old -N ones were. (We may be there
now, I just haven't tested enough to be sure yet.)
Why merge sooner rather than later?
Well, the branch bumps a lot of APIs, particularly in svn_client.h,
because now there are these 'svn_depth_t depth' parameters being
passed around instead of 'svn_boolean_t recurse'. The new APIs seem
pretty stable; I haven't had to change them unexpectedly since the
early days of the branch. While I'm not planning to merge right away,
I'd like to merge as soon as we're convinced that the APIs are here to
stay. If 1.5 were to release without these APIs, it'd be a royal pain
to update the branch for 1.6.x (because many of the API changes
piggy-backed onto existing new 1.5 interfaces).
What does this all mean in practical terms?
Well, of course I'd love some help on the branch :-), but then again,
everyone says that about their pet project. If you don't have time to
help, that's okay. But I'll try to stub out the new tests so that
it's easy for others to pitch in whenever they feel like it. If you
don't have time to code, just doing review would still be a help.
Once we've dealt with the problems mentioned in README.branch, and
with the more serious of the "### TODO" comments scattered throughout
the code, I'd like to merge, even if not all the kinks are worked out.
So I wanted to start this discussion now, in parallel with the work.
If people think the feature should be all nice and shiny before we
merge it, better to find that out now that later.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 22 04:27:38 2007