First, see my response to this thread: http://www.webdeveloper.com/forum/showthread.php?p=1144867#post1144867
Now, as a member of a client organization dealing with larger development firms, I've found that, while there is no single way to do things, there are some patterns to follow:
Use subversion or CVS. Simple -- just make sure your project is under some version control somewhere. So far, I have yet to encounter anyone using anything other than subversion.
Multiple working copies. You'll have multiple functioning copies of the application, each of which gets updated on a different schedule, and each of which will have different levels of reliability and testing needs. So, you may end up with "layers" like this:
Lives on: the actual development machine(s): you and your co-developers' local PCs, macbooks, etc.
Updated: constantly -- every time code is changed.
Reliability: consider these copies highly unreliable -- they should have their own data sets.
Lives on: a publicly accessible server, possibly password protected to protect IP, which may or may not live on the production server
Updated: often -- daily, weekly, or whenever you accomplish something and are reasonably sure it's stable
reliability: pretty low -- it uses its own dataset, which may even have a lot of lingering structures from past explorations and tests
Lives on: a publicly accessible server, which may or may not be the alpha and/or production server
Updated: whenever the project on alpha reaches a state that is ready for final QA before going to production
reliability: pretty good -- beta environments can sometimes even share data with production, depending on whether there are outstanding schema updates to make to the production dataset
Self explanatory -- the public application.
Now, some firms will break down alpha, beta, or staging environments even further. Some developers will simply have one beta environment that serves most or all non-production needs. And how you lay these all out on hardware is really up to you. If you're working on a multi-core machine and ensure that your database connections are configured safely and correctly, you generally don't have to worry about your dev/alpha/staging copies affecting live. And if everything is on the same hardware, it can make turning your alpha into beta and beta into staging and staging into production really snappy.
In terms of the virtual hosting setup -- I tend to prefer giving each stage its own hostname:
local.sitename.com : local hosts entry -> 127.0.0.1
alpha.sitename.com : local OR actual DNS entry -> alpha server
beta.sitename.com : actual DNS entry -> beta server, could be same as alpha or beta
staging.sitename.com : actual DNS entry -> probably same as live server
www.sitename.com : actual DNS entry -> live server ... obviously.
And the application needs to be smart enough to "know" which host it's working under, refer to files correctly, and use the right data resources. For me, I have found that this is best done placing a localconfig file on each environment that lives outside the repository or "project" (if using an IDE), that will not be overwritten on accident, and serves to rewrite a set of default values. (so the site functions as the LIVE site in the absence of that file -- so when you package up the app and hand it off, you don't have to worry about forgetting to include some file that doesn't exist in your project)
... is that at all helpful? Sorry for the rambling.