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

Re: code release cycle under svn

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-04-03 22:43:27 CEST

On Mar 30, 2007, at 06:42, Greg Rundlett wrote:

> Using a working copy on the production server *is* the best
> approach, which I
> call the 'pull' approach. You pull updates using svn update. Have
> a problem
> in production? you instantly revert changes using svn switch -r PREV.

Note that svn update is not an atomic operation. From the time that
you issue the svn update command until the time that it completes
successfully, your web site is potentially in an inconsistent state
and, depending on how it's programmed and the changes that will occur
in the to-be-retrieved revisions, may not function properly. Note
also that if a network problem occurs during the svn update
operation, it may exit with an error, leaving the web site in an
inconsistent state until you successfully complete svn update.

For these reasons I prefer to keep a working copy on the server, but
not point Apache's document root directly to it. Rather, once the
update completes, I svn export the working copy to a new directory,
whose name is unique (could be based on the revision number, for
example, which you can find using svnversion). I also have a symlink
with a name like "current" which I relink to the newly created export
directory (ln -sf export-r1234 current). Apache's document root
points at the "current" symlink. Then old exported directories can be
deleted to free up disk space, if desired. Or the last one or two can
be kept around, in case of a need to roll the web site back to a
previous version -- instead of having to wait for an svn up -r PREV
to complete, you can simply relink "current" back to the previously
exported directory.

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 3 22:48:00 2007

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.