Re: svn client api comments

Martin Hauner <hauner@web.de> writes:

> Is there any reason why svn_client_add does take a const char* and
> not a const apr_array_header_t* like revert and delete?

Historical reasons; they all took single paths originally, add has
never been updated to multiple paths.

> subcommanders c++ wrapper for add takes a list as input and calls
> svn_client_add for each file. That's an easy workaround. But I think
> the svn api would be a bit cleaner if add took a list too.

It could be much more efficent as well, the current interface reads
and writes an entries file for each path. For paths in the same
directory that's inefficient.

> svn_copy: takes a single input file
> svn_move(2): takes a single input file
>
> It would be nice if those two took a list of files to copy/move as input.
> If i move or copy source files in a working copy i typically want to move
> a header and its source file together.
>
> For the working copy case i can do the same as for add above, but in case
> of copying or moving directly in the repository it wouldn't be a good idea.
> Each single repository move or copy would request its own commit message...
> and not just one message for the move/copy of all (selected) files.

That's harder. There is 'destination logic' such that

   svn_client_copy "src" "dst"

will create "dst/src" if "dst" is an existing directory, and "dst" if
"dst" does not exist. That sort of behaviour is fine for the
application, but is not good for the client API as it makes it
impossible for an application to know in advance if it's going to
create "dir/dst/src" or "dir/dst".

It would be much better if the client API had predictable behaviour.
The 'destination logic' should be moved out of copy/move, either into
some wrapper function or simply into the application.

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