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

"svn copy" semantics: replace vs. place into

From: Stephen Gildea <gildea_at_stop.mail-abuse.org>
Date: 2005-10-24 19:26:46 CEST

One of the steps we would like to do when installing from our "devel"
branch onto our live server is to update the moving tag "installed",
which is always what's installed on the server. We'd like to

$ svn copy https://repos/svn/project/devel https://repos/svn/project/installed

We want the current "devel" to replace the current "installed".
But Subversion 1.2 wants to create "devel" as a subdirectory of
the existing "installed" directory.

Looking at the mailing list archives, I see this same issue was
discussed in October 2003. From that discussion,
http://svn.haxx.se/users/archive-2003-10/0019.shtml seems to sum
up my problem best.

That same thread says that this issue is bug 1516, currently fixed
in development sources and targeted for 1.4. That bug does
address the issue of atomic replace in the repository, but I don't
see that it addresses the semantics of "svn copy"--whether it does
a replace or a place into.

Could someone please confirm for me that with this bug fixed,
there is some way to do an atomic repository replace? Perhaps
with "svn copy SRC_URL DST_URL", perhaps with some other syntax.

One workaround we are considering is to do

$ svn delete https://repos/svn/project/installed
$ svn copy https://repos/svn/project/devel https://repos/svn/project/installed

but of course that is not atomic.

Another solution for us would be if there were a way to generate a
transaction to send to the server without having a working copy
that included all the branches.

 < Stephen

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 24 20:45:07 2005

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.