On Jan 14, 2008, at 13:43, Les Mikesell wrote:
> Shawn Talbert wrote:
>
>> I kinda like a hybrid version of the ones you mention:
>> 1. use svn update (to efficiently update) to some staging area on
>> the web server
>> 2. svn export that to the real web folder (this avoids polluting
>> with svn metadata).
>
> You can also use rsync with the -C (or --cvs-exclude) option to
> copy from a staging workspace to the production destination(s).
> This originally was intended for cvs metadata but also skips .svn/
> contents. Rsync has the advantages of using less bandwidth for
> remote copies and copying in under a temporary name and renaming to
> the original when the transfer is complete so the running
> application does not see partial files.
The version we used is roughly:
1. svn switch an existing working copy to a new release tag, so the
update from the repository is efficient
2. svn export the working copy to a new directory, named for the tag
3. delete the symlink "current"
4. recreate the symlink "current" to point at the latest exported
directory
Deleting and recreating the symlink is of course very quick, so
switching from one version of the site to the next is fast and,
importantly, consistent. If your web server points directly at your
working copy, then during the time that your update is running (which
could be awhile if your network is slow or if there are many
changes), your web site is in an inconsistent state (partly updated,
partly not updated) which sounds like a bad idea to me. Also, an
update can and sometimes does fail in the middle, leaving your web
site in that inconsistent state. Better to prepare the new version in
a new directory, and only when it's completely ready, point the web
server at it (by redirecting a symlink).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-14 21:00:27 CET