Ben Collins-Sussman <sussman@collab.net> writes:
> On Dec 18, 2004, at 10:14 AM, SteveKing wrote:
>
>> Ben Collins-Sussman wrote:
>>
>>> This is a pretty persuasive argument. In other words, you're
>>> suggesting that we let the *caller* decide whether to create a new
>>> directory or not. svn_client_move2() should either throw a
>>> specific error if the target already exists (which the client can
>>> trap), or it could take a new boolean argument to toggle
>>> directory-creation behavior.
>>
>> It's not just svn_client_move() - svn_client_copy() has the same
>> behaviour (as I mentioned in the example creating the tag).
>>
>>> These API changes seem reasonable to me. Of course, the
>>> commandline client shouldn't change it's behavior here, but at
>>> least we can offer more options for other clients.
>>
>> Should I file an issue about this?
>
> Let's wait a day or two more, to see if others agree. :-)
I agree the existing behaviour is undesirable for URL destinations.
The current libsvn_client implementation also suffers from a "check if
the destination URL exists" race which is probably an indicator that
the code doesn't belong in the library. I see no problem moving that
check into the client.
When the destination is a wc path it's less clear cut; the library
itself doesn't have a race, but there is still a race if the client
want's to check before calling the library function. Clients that
desire the existing behaviour currently get it without a race, moving
the check into the client would introduce a race. I suppose that
means we need to make the existing behaviour optional in the library.
Then the question arises, should it be optional for URLs as well?
These days I feel it was a mistake to make functions like
svn_client_move handle both URLs and wc paths, separate functions
would probably be better. I think a reasonable case can be made that
svn_path_is_url should only be used by the client and not by
libsvn_client.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 18 18:28:55 2004