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

Re: unexpected behaviour (bug?) when moving/copying

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-18 16:59:27 CET

On Dec 18, 2004, at 9:50 AM, SteveKing wrote:

> Ben Collins-Sussman wrote:
>
>> Oops, sorry, I read too quickly. So TSVN could prompt the user if
>> they want the directories to be 'merged' together the way explorer
>> normally does. If so, then TSVN can 'svn copy' each dir1\* object
>> into targetdir\, right?
>
> I'm not really in need of Subversion doing a merge here. What worries
> me a little is that the Subversion library behaves like the CL client
> instead of like all other libs I know. Example:
> svn_client_move()
> behaves the same way as
> svn mv
> But move commands in libraries usually behave different. Just check out
> apr_file_move()
> Such a library function would never just create a new subfolder if the
> target folder already exists. It's up to the client program to check
> that and decide what to do in such a case. If the library just creates
> a subfolder and doesn't throw a warning or an error, it's very
> difficult for a client to implement its own behaviour.
> I mean, if
> svn_client_move() would just overwrite the target, ok. Better would be
> if the function had a force flag and throw an error if the target
> exists and the force flag isn't set. That way a client program could
> immediately see the target exists and decide what to do. But as long
> as everything seems to work ok, a client program would have to do a
> lot of checks before even calling the library function.
>

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.

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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 18 17:00:53 2004

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.