Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: svn update or rsync - which is best to update live files
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: Ryan Schmidt <subversion-2011a@ryandesign.com>
In-Reply-To: <43BD16D5-E564-4D30-A50C-018D43818DF5@orcaware.com>
Date: Sat, 26 Feb 2011 17:39:09 -0600
Cc: Christopher D Haakinson <cdhaakin@us.ibm.com>,
 Subversion Users <users@subversion.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <00FA3E8B-0373-4219-ADD7-32DB34D78389@ryandesign.com>
References: 
 <OF6D565698.3826E2CF-ON87257842.006B8CED-85257842.006BF314@us.ibm.com>
 <4D6808D3.4070707@orcaware.com>
 <E18477E2-5759-4FC9-BB50-34BDE3974C71@ryandesign.com>
 <43BD16D5-E564-4D30-A50C-018D43818DF5@orcaware.com>
To: Blair Zajac <blair@orcaware.com>

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

> On Feb 26, 2011, at 2:47 PM, Ryan Schmidt wrote:
>=20
>> On Feb 25, 2011, at 13:53, Blair Zajac wrote:
>>=20
>>> 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.
>>=20
>> 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.
>=20
> 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.
>=20
>> 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:
>>=20
>> http://svn.haxx.se/users/archive-2009-04/0083.shtml
>=20
> Right, the symlink approach gets you 90% there.
>=20
> 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.