On Mon, Jun 23, 2008 at 6:40 AM, Ryan Schmidt
<subversion-2008b_at_ryandesign.com> wrote:
> 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.
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. 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.
Just wanting to point out the facts as they are, nothing personal
(infact: thanks for your continued contributions to the list!)
Bye,
Erik.
---------------------------------------------------------------------
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-25 23:30:10 CEST