On Jun 22, 2008, at 2:29 PM, Michael Caplan wrote:
> I'm looking for some information on how the switch command actually
> goes about
> updating files. Basically, I'm looking at using SVN and switch in
> order to
> update code in a sandbox on a website. The concern is serving up
> half written
> files while the switch command is running.
>
> Does "switch" replace the files in an atomic manner on the file
> system so that
> half written files are not served?
>
> The PHP APC docs explain the issue best:
>
> “When you modify a file on a live web server you really should do
> so in an
> atomic manner. That is, write to a temporary file and rename (mv)
> the file into
> its permanent position when it is ready. Many text editors, cp, tar
> and other
> such programs don’t do this. This means that there is a chance that
> a file is
> accessed (and cached) while it is still being written to. ... The
> unfortunate
> person who accessed this half-written file will still see
> weirdness... ” -
> http://ca3.php.net/manual/en/apc.configuration.php
>
> I looked at the SVN docs and can’t find any details on the method
> used to update
> files when running switch.
svn switch, like its lesser cousin svn update, is not atomic.
What we did for our web sites was to have a working copy of the web
site files on the web site server, but not point Apache at that. We
would svn switch that working copy to whatever new tag we wanted to
use on the web site server, and once the switch was completed, we
would svn export the working copy to a new directory whose name was
based on the tag name. Then we would remove a symlink "current" and
repoint it at the new export. Apache's docroot was pointed at that
current symlink. That way it's a nearly-atomic operation to remove
and recreate the symlink -- there's only a split second during which
the symlink doesn't exist -- and should you need to return to the
previous version of the site for some reason, it's just as simple to
change the symlink back to your previous export. Keep a few previous
version around, and delete older ones. We had a script we used to
deploy to the server which automated all this.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-23 06:40:59 CEST