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