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

Re: Chained svns

From: Ryan Schmidt <subversion-2008c_at_ryandesign.com>
Date: Tue, 23 Sep 2008 10:11:04 -0500

On Sep 23, 2008, at 7:15 AM, John Doe wrote:

> I am new to the list, to svn and rcs in general...
> I looked at the FAQ and the list's archives but did not find
> exactly what I was looking for.
> Basicaly, we have an office, where we have devel and pre-
> production, and a production website hosted at a datacenter.
> What would be the best way to setup this with subversion...?
> One mandatory point: no rsync and no live svn update through the
> (potentialy unstable) network.
> I was thinking of something like chained svns one at the office and
> one at the datacenter.
> But I am a bit confused between branches, vendor branches and tags.
> Would
> an office svn with a trunk (pre-prod) branch and a devel branch + a
> datacenter svn with a vendor branch pointing to the office svn
> work...?
> It
> would go like merge devel into trunk at the office. Then merge
> "vendor
> branch" (office trunk) at the datacenter. Then svn update localy at
> the datacenter.
> Does it make sence and/or is there an easier/better way to do this?

You can run a mirror of your Subversion repository at your datacenter
if you want. The tool is called svnsync.

However it sounds like your real goal is to have a web site at your
data center, and the content of the web site comes from the
repository. In that case, you want what you don't want: you want to
"svn update" the web site at the data center when changes are made to
your development server.

You're right that a potentially unstable network can cause problems
for "svn update". Unlike operations which write to the repository
(like "svn commit"), "svn update" is not atomic. So what we did at
the company where I worked was to "svn update" a working copy that
the web server didn't know about. When that was done, we used "svn
export" to create a new directory whose name was based on the tag
name (or you could use the revision number or the date if you're not
using tags). Finally, a symlink "current" was deleted and re-pointed
at the new export directory. And the web server only knew about the
symlink. In this way, you can easily and very quickly change your
live site from one version to the next -- and even go back to a
previous version if necessary (just put the symlink back to an older

There's a perl script that has been helpfully written to help with
these type of deployments. I haven't had a chance to use it, but
perhaps it will help you:


To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-23 17:11:36 CEST

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.