[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

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.