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

RE: Switch and File Modification in Atomic Manner?

From: Caplan, Michael <Michael.Caplan_at_henryschein.com>
Date: Mon, 23 Jun 2008 07:28:57 -0600

Thanks for that Ryan!

Best,

Mike

> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2008b_at_ryandesign.com]
> Sent: Monday, June 23, 2008 1:40 AM
> To: Caplan, Michael
> Cc: users_at_subversion.tigris.org
> Subject: Re: Switch and File Modification in Atomic Manner?
>
> 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.

Please consider the environment before printing this email.

E-mail messages may contain viruses, worms, or other malicious code. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective action against such code. Henry Schein is not liable for any loss or damage arising from this message.

The information in this email is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this e-mail by anyone else is unauthorized.

---------------------------------------------------------------------
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 17:26:23 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.