subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: svn update or rsync - which is best to update live files
Date Sat, 26 Feb 2011 23:39:09 GMT
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
>> 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:
> 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

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

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.

View raw message