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

Re: Why "svn copy" and "svn move" can't accept more than one SRC?

From: Liu Yubao <yubao.liu_at_gmail.com>
Date: 2006-10-09 07:28:38 CEST

Karl Fogel wrote:
> Liu Yubao <yubao.liu@gmail.com> writes:
>> The "add", "delete", "mkdir", "list" subcommands all can operate on
>> many targets, but "svn copy" and "svn move" don't act that way.
>>
>> I searched svn.haxx.se and haven't found a good explanation, I known I
>> can use shell command to run these two commands repeatly, but I am
>> still curious about the reason for this CLI design.
>
> I searched the issue tracker and didn't find any history about this.
> I haven't search the mailing list archives, you might want to try there.
I find this thread:
http://svn.haxx.se/users/archive-2005-01/0790.shtml
>
> Off the top of my head, I can't think of any good reason for this CLI
> design, and maybe we should change cp and mv to take >2 arguments. I
> remember some discussion about this a few years ago, but I don't
> remember the details of that discussion very well.
>
> -Karl
>
        http://subversion.tigris.org/issues/show_bug.cgi?id=747
        "Note: this is a bit harder than it initially seems. If the target is a
         URL, then we want to collapse everything into a single commit (e.g.
         looping over svn_client_move() would create multiple commits)."

It seems a limitation of svn client API, svn_client_move()
and svn_client_copy() all call setup_copy() in libsvn_client\copy.c,
this function can accept only one src_path.

I think these APIs can be enhanced and won't bring too much complexity.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 9 07:29:53 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.