The discussion about this can be found here:
http://svn.haxx.se/dev/archive-2004-12/0797.shtml
(note: I did not get permission to file this issue, but after "Let's wait a day
or two more, to see if others agree." and another mail from me asking for
permission I didn't get any answer. So I'm filing this issue now anyway - feel
free to kill it if you like).
So here it goes:
The API's svn_client_move() and svn_client_copy() behave currently the same as
the commands 'cp' and 'mv' do: if the target already exists, a foldername from
the source is automatically appended:
$ svn copy file:///f:/test/testrepo/trunk \
file:///f:/test/testrepo/tags/version1 -m "tagging trunk"
Revision 4
$ svn ls -v file:///f:/test/testrepo/tags/version1
4 kueng Dez 18 14:00 trunk/
As you can see, a 'trunk' is automatically appended to /tags/version1.
This is ok for the command line client (and shouldn't change there). But this
behaviour is implemented in the API, not the command line client. Other clients
(especially GUI clients) don't want that behaviour because it confuses most
users (both the windows explorer and the file browser in KDE behave differently).
So what I'm requesting is that the API should error out if the target exists
(maybe with a --force flag to overwrite) and not just create another folder
instead. It should let the caller/client decide what to do in such a case. The
command line client then could still decide to create that folder.
To not break compatibility, I suggest new API's svn_client_move2() and
svn_client_copy2().
The problem is: as long as the API makes decisions itself, the client(s) can't
do anything about that.
Comment from Ben-Collins Sussman
(http://svn.haxx.se/dev/archive-2004-12/0807.shtml):
<<This is a pretty persuasive argument. In other words, you're
suggesting that we let the *caller* decide whether to create a new
directory or not. svn_client_move2() should either throw a specific
error if the target already exists (which the client can trap), or it
could take a new boolean argument to toggle directory-creation
behavior.
These API changes seem reasonable to me. Of course, the commandline
client shouldn't change it's behavior here, but at least we can offer
more options for other clients. >>
Bug
Critical