Daniel Patterson <danpat@danpat.net> writes:
> And here's a patch against trunk to do just that.
Thanks for the quick action, Daniel!
Comments on the patch:
> [[[
> Add a --non-recursive option to "svn export"
>
> * subversion/libsvn_client/export.c:
> (svn_client_export3): deprecate and call svn_client_export4,
> defaulting to old recursive behaviour.
> (svn_client_export4): add a "recursive" flag which gets passed
> through to svn_ra_do_update.
>
> * subversion/clients/cmdlind/export-cmd.c:
> (svn_cl__export): use new svn_client_export4 function and pass
> inverse of --non-recursive command line through. Still defaults
> to the original behaviour of a recursive export.
>
> * subversion/clients/cmdline/main.c:
> (svn_cl__cmd_table[]): add "N" option to "export" command
> ]]]
Hmmm, I don't see any svn_client.h changes in there. They would be
needed, because you'd have to publish the new svn_client_export4 API,
and deprecate the old svn_client_export3 API, in the usual way. (See
examples in the other header files, see HACKING).
However, since svn_client_export3 is new in 1.2 anyway, and 1.2 has
not been released yet, there's no need to make svn_client_export4.
Just change svn_client_export3 as you need (remember that its API docs
will need updating in svn_client.h too).
Also, while not absolutely required, a regression test for the new
feature is a huge bonus, and gives a patch higher precedence.
> Index: subversion/libsvn_client/export.c
> ===================================================================
> --- subversion/libsvn_client/export.c (revision 13057)
> +++ subversion/libsvn_client/export.c (working copy)
> @@ -737,13 +737,14 @@
> /*** Public Interfaces ***/
>
> svn_error_t *
> -svn_client_export3 (svn_revnum_t *result_rev,
> +svn_client_export4 (svn_revnum_t *result_rev,
> const char *from,
> const char *to,
> const svn_opt_revision_t *peg_revision,
> const svn_opt_revision_t *revision,
> svn_boolean_t force,
> svn_boolean_t ignore_externals,
> + svn_boolean_t recursive,
> const char *native_eol,
> svn_client_ctx_t *ctx,
> apr_pool_t *pool)
> @@ -851,7 +852,7 @@
> &reporter, &report_baton,
> revnum,
> "", /* no sub-target */
> - TRUE, /* recurse */
> + recursive, /* recurse */
> export_editor, edit_baton, pool));
>
> SVN_ERR (reporter->set_path (report_baton, "", revnum,
> @@ -913,6 +914,22 @@
> return SVN_NO_ERROR;
> }
>
> +svn_error_t *
> +svn_client_export3 (svn_revnum_t *result_rev,
> + const char *from,
> + const char *to,
> + const svn_opt_revision_t *peg_revision,
> + const svn_opt_revision_t *revision,
> + svn_boolean_t force,
> + svn_boolean_t ignore_externals,
> + const char *native_eol,
> + svn_client_ctx_t *ctx,
> + apr_pool_t *pool)
> +{
> + return svn_client_export4 (result_rev, from, to, peg_revision,
> + revision, force, ignore_externals, TRUE,
> + native_eol, ctx, pool);
> +}
The shape of the code change looks correct to me. I haven't actually
tested it yet (this is one reason a regression test is handy).
Shockingly, the 'recurse' parameter of svn_ra_do_update is not
documented right now, a fact which makes it more difficult than it
should be to verify your change. Nor is that parameter documented for
svn_client_checkout2. Grrr. Inspection of the code indicates that
the 'recurse' flag does what we all think it does, anyway.
I'll fix these documentation bugs. They're not related to your patch,
except insofar as your patch caused them to be noticed.
Good change, overall. Can you resubmit it as described above? (Or if
you don't have time, let me know, and I can make the adjustments.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 19 01:05:44 2005