[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: Ryan Schmidt <subversion-2008b_at_ryandesign.com>
Date: Wed, 25 Jun 2008 23:24:07 -0500

On Jun 25, 2008, at 16:29, Erik Huelsmann wrote:

> On Mon, Jun 23, 2008 at 6:40 AM, Ryan Schmidt wrote:
>> On Jun 22, 2008, at 2:29 PM, Michael Caplan wrote:
>>> 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.
> While your answer about the output of the update command as a whole is
> correct, the OP seems to be asking about the file-level.

Oh yes. You are right! I overlooked that.

> On the file
> level, Subversion will never write half-written files into the working
> copy: it uses exactly the method described in the PHP ARC manual. Why?
> Because it could be a data loss issue if we didn't: imagine updating a
> file with local changes at the end of the file. If we were to simply
> overwrite that file in the wc, when hitting an error half-way down,
> your changes will have been lost!
>> 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.
> Ofcoures, this assures that *all* files have been correctly updated,
> which addresses the 'non-atomicity' of the update command as a whole.
> A much more reliable solution for the problem you're presenting
> indeed.

For web sites that are just a collection of unrelated HTML files and
images and such, a simple update would be ok. But our sites were PHP
monstrosities with page A including library B which needed flanges C
and D and grommets E through J. We felt it prudent to update
everything at once, not file by file.

> Just wanting to point out the facts as they are,

I wouldn't have it any other way! :-P

> nothing personal
> (infact: thanks for your continued contributions to the list!)

"HTH"! :-)

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-26 06:24:47 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.