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

Re: "svn cp" too smart about existing directories?

From: Ryan Schmidt <subversion-2006c_at_ryandesign.com>
Date: 2006-08-22 01:15:10 CEST

On Aug 21, 2006, at 15:09, Johan Holmberg wrote:

> When I create a branch or tag I use a command like:
> $ svn cp -mMSG http://HOST/myproj/trunk \
> http://HOST/myproj/branches/foo
> But I just discovered that I can issue the same command two times
> without getting an error the second time. The *third* time I get an
> error. I had hoped that the second time would give and error.
> The explanation seem to be that "svn cp" is "smart" the second time
> and detects that the directory "myproj/branches/foo" exist, and
> then decides to create "myproj/branches/foo/trunk" instead.
> I have looked around and tried different ways to disable this
> behaviour, but without any success.
> It seems that "svn cp" is using the same tactic as cp(1) on UN*X.
> But is this really a good idea? It seems to me that it should be
> possible to write a "svn" command in such a way that it *means* the
> same thing, independently of how what repository happens to looks
> like.
> ( I come to think about rsync(1) that has solved this by having
> trailing "/" being significant in pathnames )
> Have I missed some way of accomplishing what I want?

No, I don't think you've missed anything. Yes, Subversion does
function the way you describe, and I believe it is indeed because
that's the way the standard Unix cp command works. I don't know of
any way to disable that behavior there either.

If you want to receive an error when copying to a location that
already exists, instead of having Subversion copy into that location
as it currently does, you could probably write a wrapper script
around the svn command which works in this manner.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 22 01:16:46 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.