Re: API proposal - issue 2188 - svn_client_copy/move

[Garrett Rooney <ro...@electricjellyfish.net>]

On 10/27/05, Madan U Sreenivasan <ma...@collab.net> wrote:

> 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
> exists
>
> 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
> existing
>      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
> etc.,)

If we're going to add a parameter to control this kind of behavior,
I'd also like to add the ability to overwrite the file/directory
that's present in the destination.  To be really useful this should
also apply to copy in addition to move.  This is a fairly commonly
requested feature (say for example if you want to have a "currently
installed version" tag, whenever you recreate it you have to do a
delete then a copy).

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: API proposal - issue 2188 - svn_client_copy/move

[Garrett Rooney <ro...@electricjellyfish.net>]

On 10/28/05, Philip Martin <ph...@codematters.co.uk> wrote:

> Once the library provides an interface with predictable behaviour the
> application can implement all the "smart" behaviour on top.  Quite how
> much of the "smart" behaviour should be moved into the library is a
> hard question to answer, one reason for putting it in the library is
> that it might be possible to do things more efficiently (fewer RA
> calls) in the library than in the application.

The problem is that unless the application is ok with implementing
their behavior in terms of the libsvn_ra interface, they currently
can't implement this sort of behavior because of race conditions. 
There's no higher level API that allows you to say "replace this
directory with this other directory" because in between you deleting
the first directory and copying the second one in place another commit
could have placed something there, so your new copy ends up as a
subdirectory instead of the location you wanted.

The current libsvn_client APIs just don't posses the flexability to
allow the applications to provide the "smarts" that are needed. 
There's no way to say "copy this to location /foo, but if another
directory shows up there in the meantime error out", and even if we
had that, you still couldn't implement the "replace /tags/foo with a
copy of /trunk" all in one commit, it would have to be split into two
commits, and the second could potentially fail due to a race
condition..

> > If we're going to add a parameter to control this kind of behavior,
> > I'd also like to add the ability to overwrite the file/directory
> > that's present in the destination.  To be really useful this should
> > also apply to copy in addition to move.  This is a fairly commonly
> > requested feature (say for example if you want to have a "currently
> > installed version" tag, whenever you recreate it you have to do a
> > delete then a copy).
>
> Are these requests for an application interface, "svn cp/mv", or a
> library interface, "svn_client_copy/move"?

I've seen people ask for both a command line level interface and a
language bindings level interface, which implies that the change
should be at the libsvn_client library interface and then exposed via
the command line and bindings.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: API proposal - issue 2188 - svn_client_copy/move

[Philip Martin <ph...@codematters.co.uk>]

Garrett Rooney <ro...@electricjellyfish.net> writes:

> On 10/27/05, Madan U Sreenivasan <ma...@collab.net> wrote:
>
>>   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
>> existing
>>      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
>> etc.,)

Once the library provides an interface with predictable behaviour the
application can implement all the "smart" behaviour on top.  Quite how
much of the "smart" behaviour should be moved into the library is a
hard question to answer, one reason for putting it in the library is
that it might be possible to do things more efficiently (fewer RA
calls) in the library than in the application.

> If we're going to add a parameter to control this kind of behavior,
> I'd also like to add the ability to overwrite the file/directory
> that's present in the destination.  To be really useful this should
> also apply to copy in addition to move.  This is a fairly commonly
> requested feature (say for example if you want to have a "currently
> installed version" tag, whenever you recreate it you have to do a
> delete then a copy).

Are these requests for an application interface, "svn cp/mv", or a
library interface, "svn_client_copy/move"?

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org