Max Bowsher wrote:
> Philip Martin wrote:
>> "Max Bowsher" <maxb@ukf.net> writes:
>>> 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.
Yes: in particular, the removal of uncertainty (issue #2188).
This applies to "copy" as well as "move", and we should have no qualms about
"revving" the svn_client_copy API as well.
First observation: Good Grief! The API documentation doesn't mention any
possibility of the destination path being interpreted differently depending on
whether it already exists and whether it is a file or directory.
>> There is another enhancement that has been requested: allow multiple
>> source URLs to be moved or copied into a single destination URL,
>> i.e. make the source argument into an APR array.
Hold it. I thought a bit about extending move/copy in this way, but there is
no good, simple, generic solution. When we start talking about multiple
operations being part of the same commit, we should discuss an API that allows
multiple arbitrary operations, not just certain restricted forms of "copy" and
"move". (For example, the form suggested doesn't allow for renaming as part of
the move.) Let's leave that discussion for another time.
>>> 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.
[...]
>> Another trivial solution is to move the logic out of libsvn_client
>> altogether and put it in the application.
Yes.
> No, because the current API must remain compatible, so such code must
> remain in libsvn_client, so we might as well make the convenience
> available to client writers.
That is not necessarily the best approach. Yes, a copy of the logic must
remain in libsvn_client for compatibility, but we should still change the API
to whatever is best even if that means that the client has to grow another copy
of the logic.
>>> HOWEVER, I think there is a better API change:
>>>
>>> Add a new tri-state enum parameter:
>>>
>>> enum {
>>> svn_copymove_collision_error,
>>> svn_copymove_collision_make_child,
>>> svn_copymove_collision_replace
>>> };
No, that's making the API too complex. It should do one task and do it well.
Certainly the "error or replace" part is useful, but there is enough complexity
already and automatically making a child is just too much.
A sensible remit for this API is to copy (or move) an item while possibly
renaming it. Therefore it should take the source full pathname and the
destination full pathname of the item, and copy/move the one to the other. If
the parent directory of the destination does not exist, it should either error
or create all intermediate directories. If the destination exists, it should
either error or overwrite it. We could make design-time decisions on those
options, or the functions could take boolean parameters to control those options.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 1 21:19:45 2005