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

Re: Remote Deployment

From: Phil Endecott <spam_from_subversion_users_at_chezphil.org>
Date: 2005-11-29 22:55:03 CET

Scott Brady wrote:
> We have an external production server with an obvious purpose.
> Currently, using VSS, we would "Get Latest" to our internal servers and
> FTP files from QA to Stage and from Stage to Production.
> What we'd really like to do is to be able to send files from our
> repository to not only our internal servers but also to the external
> servers
> 2) Install an SVN client (such as TortoiseSVN) on the external servers,
> the[n] remote into those servers and essentially do an "Update local copy"
> from our internal repository.

Yes, that's probably the way to do it.
Some minor points are:
Being a working copy it will contain .svn directories; either configure
the web server to hide them or do "export" each time rather than "update".
Updates are not atomic. If this matters, i.e. you don't want the danger
of broken pages being server even for a moment, update into a parallel
directory and "flip a switch" somewhere (in Unix-land we have symlinks)
to change over atomically.

You could use a post-commit hook to automate some of this, but I suggest
that you don't try that until you have something working manually.
Typically in your setup you would have a "deployed" branch, and after QA
approval you'd copy the new content into this "deployed" branch. The
production server would have a checkout of only this branch, updated
from the hook, so normal commits to the trunk and elsewhere don't change
anything on the production server.

The hook script runs on the machine where the repository lives; if
that's not the production server where the automatic update needs to
happen, you need a remote command execution mechanism. "ssh
production_server -c svn update" might be all you need.

I don't see why you think you need svn:externals; I think you're
misunderstanding something there.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 29 23:06:05 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.