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

Re: svn commit: r18315 - in trunk/subversion: include libsvn_client svn tests/cmdline

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-02-01 23:27:16 CET

On Wed, 1 Feb 2006, Garrett Rooney wrote:

> On 2/1/06, lundblad@tigris.org <lundblad@tigris.org> wrote:
> > Author: lundblad
> > Date: Wed Feb 1 16:53:34 2006
> > New Revision: 18315
> >
> > Modified:
> > trunk/subversion/include/svn_client.h
> > trunk/subversion/libsvn_client/copy.c
> > trunk/subversion/svn/copy-cmd.c
> > trunk/subversion/svn/move-cmd.c
> > trunk/subversion/tests/cmdline/copy_tests.py
> >
> > Log:
> > Fix issue #2188: svn_client_copy/move should error out if target exists.
> >
> > This change introduces new copy/move public functions with the same argument
> > lists, but with the semantic change that they always fail if the destination
> > exists. The command line client implements the old behaviour of copying the
> > source as a child of an existing target.
>
> Any reason this has the compat glue in the client instead of making
> the behavior optional via a new parameter or something? I'm thinking
> an enum that controls the behavior, leaving us with the option of
> later implementing the ability to overwrite the existing item without
> having to rev the API again...
>
maxb proposed that right before 12 was released; many people wanted to
move the createchildifexist logic out of the function to simplify the API.
Some of the threads are linked to the issue. Note that in the cmdline
client, this is not compatibility code, it is just how the cmdline client
wants to handle a particular failure case.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 1 23:28:00 2006

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.