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

Re: API proposal - issue 2188 - svn_client_copy/move

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2005-10-28 01:42:49 CEST

On Sat, 2005-04-02 at 04:21, Max Bowsher wrote:
> kfogel@collab.net wrote:
> > Given the length and complexity of this conversation, I think it would
> > be a mistake to try to get even just the API change into 1.2.
> >
> > Realistically, we can't design the API without understanding the use
> > cases and the interface anyway. But we don't want to rush those.
> > Therefore, how about having this discussion continue, but aimed toward
> > 1.3 not 1.2?
> I think so. It's obviously more complicated than I'd hoped.
> Kicking 2188 to 1.3.
I see that after a patch and rejecting it too, nobody seems to exactly
know what is to be done regarding this. So, here am proposing what I
think is right. Pl. feel free to criticize(and hey, dont forget to
suggest an alternate ;) )

The pain area as of now is
- The inability to return error when the destination folder already

The compatibility issue as of now is
- svn client behavior should be retained

  I propose a simple extra parameter - on_dir_exists to the copy and
move API that dictates how to handle the situation of the directory
     a value of
     svn_error_if_dir_exists - does exactly that
     svn_make_sub_dir_if_dir_exists - does exactly that

     with a default value of svn_error_if_dir_exists.

Other problems
Ability to copy multiple source urls to a single destination url, when
implemented would need to call the copy/move API, with a on_dir_exists
value of svn_error_if_dir_exists and can be built around this solution.

   I'd like comments on the idea(including the variable names/values


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 28 01:55:24 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.