application we put the whole

What we generally do, at work is :

before we update, the document root of the server is :

in /www/app-2009-09-01
but is accessed via a symbolic link, called /www/application

we put the whole new code base to /www/app-2009-09-08
once the whole code base is there :

we remove the old symbolic link
we create a new symbolic link, still called /www/application, but which points to the new sources : /www/app-2009-09-08

we reload apache to force the modification to be taken into account.

All this process is done via an automatic script (the only not-automatic thing is us launching it when needed). This means :

Everything goes fast (especially the switching of symbolic link, which is the important part)
No risk of doing an error : the script has been well-tested, and working for months/years

Another advantage of this symbolic link precedure is that it is very easy to "rollback" an update if we notice a catastrophic bug only after putting the new version of the sources to production : we just have to switch the symbolic links back.

Of course, this doesn't prevent you from testing the new version on your staging server before putting it to production -- but, who knows... Sometimes, there is a really big bug that no-one has been able to see while testing :-(
For instance, because there is no load-testing done on a regular basis on the staging machine.
(I've seen the "rollback" thing used something like 4 or 5 times in 3 years -- each time, it saved the day -- and the websites ^^ )

Here is some kind of a quick example : suppose I have this VirtualHost in my Apache configuration :

<VirtualHost *>
ServerName example.com
DocumentRoot /www/application
<Directory /www/application>
# Whatever you might need here (this example is copy-pasted from a test server and test application ^^ )
Options Indexes FollowSymLinks MultiViews +SymLinksIfOwnerMatch
AllowOverride All
php_value error_reporting 6135
php_value short_open_tag on
</Directory>
</VirtualHost>

Pretty "standard"... The only thing is /www/application is not a real directory : it's just a symbolic link to the current version of the sources.
Which means when you have put the sources to the server, but not switched yet, you'll have something like this :

root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root 19 2009-09-08 22:08 application -> /www/app-2009-09-01

Notice that the symlinc points to the "old version"

Now, that the new version has been totally uploaded to the server, let's switch :

root@shark:/www
# rm /www/application
root@shark:/www
# ln -s /www/app-2009-09-08 /www/application

And, now, the /www/application points to the new version of the sources :

root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root 19 2009-09-08 22:09 application -> /www/app-2009-09-08

And we just have to restart Apache :

root@shark:/www
# /etc/init.d/apache2 restart
* Restarting web server apache2

The three steps "remove the link ; create the new link ; restart apache" should be made quickly ; ie, by an automated script, and not by a human being.

Using this solution :

you can take as much time as you need to upload the new version of the sources : apache will not use them as long as the symlic has not been changed
when everything is OK, just switch the symlink : it'll go faster than changing even 1 or 2 files... Which means virtually no downtime :-)

And if using some opcode-cache like APC with the stat option at 0, it can mean even less risk of downtime, I suppose.

Of course, this is the "simple" version -- if you have some uploaded files, for instance, you'll have to use another symlink somewhere, or another VirtualHost or whatever...

Hope this is more clear :-)