Re: svn update or rsync - which is best to update live files

On Feb 26, 2011, at 17:26, Blair Zajac wrote:

> On Feb 26, 2011, at 2:47 PM, Ryan Schmidt wrote:
>
>> On Feb 25, 2011, at 13:53, Blair Zajac wrote:
>>
>>> First, both svn and rsync do atomic replaces of the file, so you don't have to worry about the live files being observed in some odd state.
>>
>> Of course you do. The individual files may be atomically replaced, but the entire set of files won't be. If, like most web sites, your site is made with a scripting language, and file A includes file B, and both files have been changed, there will probably be a time during the update when A has been updated and B has not, or vice versa.
>
> Well, you're going past the original question. Neither rsync nor svn help with that case, as there aren't atomic updates to sets of files, which you state in the thread linked below.
>
>> Here is a previous discussion with recommendations. See especially the paragraph that starts "For finally deploying a site to the production server" and the example that follows:
>>
>> http://svn.haxx.se/users/archive-2009-04/0083.shtml
>
> Right, the symlink approach gets you 90% there.
>
> But even this doesn't get you 100% of the way there, if the browser downloads C and D and in between the symlink is changed (not talking about when A includes B that is a single GET).

Heck, there's even the problem of the web app changing between requests. What if you log into the web app when it is at version A, and then update to version B which introduces changes in the login procedure which cause additional data to be stored in the session with the login? Users who already logged into the app with version A will now be running around version B of the app without this additional information in their session, until they log out and back in.

There's tons of "what if" scenarios that should be considered. In our case, we decided that we did not want the app's files on the server in an inconsistent state for the possibly minutes it could take to run an "svn up". We decided that the millisecond it takes to delete a symlink and create a new one was a much more acceptable situation for us. YMMV.
Received on 2011-02-27 00:39:46 CET