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

API proposal - issue 2188 - svn_client_copy/move

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-04-01 18:46:58 CEST

svn_client_move has been revved to svn_client_move2 in 1.2, which makes it
an attractive idea to get some further planned changes to this API out of
the way now too.

See issue 2188 for details, but the short version is:
Clients of our API want to be able to disable the implicit behaviour of "if
copy destination exists and is a directory, append basename of the source to
the destination" that we have now. This behaviour makes sense in some
circumstances, but can prove a great annoyance in others.

So, the initial obvious solution is trivial - a new boolean parameter.

HOWEVER, I think there is a better API change:

Add a new tri-state enum parameter:

enum {

To illustrate, file:///repos/A and file:///repos/B are two directories that

  svn cp file:///repos/A file:///repos/B
  - causes error.

  svn cp file:///repos/A file:///repos/B
  - copies A to file:///repos/B/A

  svn cp file:///repos/A file:///repos/B
  - is equivalent to:
    svn rm file:///repos/B
    svn cp file:///repos/A file:///repos/B
    except that it uses only 1 revision number.

I am particularly interested in this, because I have seen emails from quite
a few disappointed users wanting to "move a tag" in just 1 revision, instead
of the 2-stage process which is the only workaround now (rm, cp).

Note that I haven't specified a UI.

In view of the impending 1.2 branch, I just want to get an acceptable API
in, in time to avoid requiring yet another round of deprecation.

The UI design can be hammered out under less rushed conditions.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 1 18:51:55 2005

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

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