Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66779
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.52 as permitted sender)
Message-ID: <514EDAF0.6030905@gmail.com>
Date: Sun, 24 Mar 2013 21:52:32 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Ferenc Kovacs <tyra3l@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <514DFAFF.4010901@lerdorf.com> <CAH-PCH4doP5+F3OksTMQVg2p3R4ne2SE6YL-6nHVJWjUW8ds_Q@mail.gmail.com> <514E2C22.4070708@lerdorf.com>
In-Reply-To: <514E2C22.4070708@lerdorf.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Continuous Integration Atomic Deploys and PHP 5.5
From: davidkmuir@gmail.com (David Muir)

On 24/03/13 09:26, Rasmus Lerdorf wrote:
> On 03/23/2013 03:01 PM, Ferenc Kovacs wrote:
>> realpath the document root(which is a symlink to the actual release
>> directory) from your index.php/bootstrap file and use that as a base
>> path for making absolute paths everywhere?
>> that way the requests started before the symlink switch will continue
>> with the old version but requests started after the switch will use the
>> files from the new revision.
>> ofc. you can still have issues like an ajax request from the old version
>> gets served by the new version, and if you have more than one server
>> sooner or later you will/have to sacrifice something from the CAP trio.
> Well, solving the multi-request/multi-server ajax scenario is a bit of a
> different problem. You'd need to version those requests to handle that.
> The scope I am concerned with here is per-server deploy atomicity.
>
> But yes, some way to have a 2-docroot scenario where all requests
> started on one via the docroot symlink stays on that one would be a good
> approach but it would take a lot of discipline at the userspace level to
> enforce that across a large and diverse codebase with autoloaders and
> actual realpath calls all over the place.
>
> -Rasmus
>

Are you saying that to allow atomic deploys with O+ you need to make
sure that all files are either autoloaded with a full realpath, or
manually included/required by the realpath?

You mentioned that O+ does not use inodes as cache keys like APC, but
what does it use instead? Just the file path?

Cheers,
David