>
> The command line client should not be using deprecated functions.
>
ok, will change that in the next version of the patch.
>> --- subversion/libsvn_client/copy.c (revision 14705)
>> +++ subversion/libsvn_client/copy.c (working copy)
>> @@ -67,6 +67,7 @@
>> svn_boolean_t is_move,
>> svn_boolean_t force,
>> svn_client_ctx_t *ctx,
>> + svn_boolean_t dir_override,
>> apr_pool_t *pool)
>> {
>> svn_node_kind_t src_kind, dst_kind;
>> @@ -93,6 +94,12 @@
>> }
>> else if (dst_kind == svn_node_dir)
>> {
>> + if ((!dir_override) && (src_kind == svn_node_dir))
>
> Is that src_kind check correct?
>
> The aim is to make "copy url_or_path1 url_or_path2" predictable,
> i.e. to allow the caller to predict the exact destination URL or path.
> As far as I can see with your patch the caller still doesn't know what
> will get created when src_kind is not a directory.
>
As far as I could make out from the discussions on the lists and the
tracker, the requirement is for the directory creation behavior of svn
copy/move to be configurable, when the dst is an existing directory.
Currently if the destination specified by the user is an existing
directory, and the src is a directory as well, then
a directory with name "dst + basename(src)" is created - this surprises
many users, who would much rather have an error thrown or make this
behavior configurable. That's what this patch allows the non-cmdline svn
clients to do - calling svn_client_copy2() with dir_override=FALSE will
result in an error and dir_override=TRUE maintains the current behaviour.
I imagine that a GUI client like Tortoise will have a have a way of
letting users configure this behaviour. If the src is a directory and
dest_kind is svn_node_none, then the contents of the src dir are copied into
the new dst dir - no directory with name = "dst + basename(src)" is created
in this case.
When the src_kind is svn_node_file, and the dst of a similar kind then an
error is thrown; if the dst_kind is svn_node_dir, the file simply gets
copied into the dst dir.
> I don't know whether it makes sense to have a flag to retain the old
> behaviour in the new function. If the "smart" destination logic was
> relegated to the deprecated functions the new functions might well be
> simpler.
>
Not sure what you mean in the last para. Can you be a little more verbose
:-).
Thanks
Ramaswamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 14 10:13:47 2005