A solution that we use with about 12 developers is the following. It works very well and makes for a flexible setup without needing to modify the server's config anymore. It probably won't scale to 40-50 devs due to network latency and speed of server storage.
We share the /var/www/ tree via Samba, so the Windows clients can use their local IDE's and VCS-clients to edit on the LAMP server. No-one has an account on the Linux server.
Create your directory structure like this:
/var/www/mysite.com/www/derek/
/var/www/mysite.com/www/paul/
/var/www/mysite.com/www/mike/
In your internal DNS, create a wildcard record that points **.dev* to your lamp server's IP address. I'm assuming 123.45.67.89 here.
In Apache, define a virtualhost that looks similar to this:
<VirtualHost 123.45.67.89>
ServerName lamp.dev
ServerAlias *.dev
VirtualDocumentRoot /var/www/%-3.0.%-2/%-4/%1/
</VirtualHost>
The important parts are the ServerAlias wildcard, which makes this vhost respond to all incoming requests that end with '.dev'. The other important one is the VirtualDocumentRoot, which looks complex but isn't so bad. It simply cuts the incoming hostname into parts and constructs the DocumentRoot out of the parts. You can read more about it here.
Now, any developer can visit http://derek.www.mysite.com.dev/ and view their personal working-copy of mysite.
Adding a new site, subdomain or developer is simply a case of creating the right directories on the Samba share.
For deploying to the Production servers, I would recommend you ditch scp and look at Capistrano, and the excellent centralized web frontend Webistrano. Capistrano is a
bit Rails-centric, but it only takes a few lines to adapt to PHP for example. Webistrano provides a central GUI where you can deploy or update a site straight from version control at the push of a button. Having easily scripted deployments, that can be repeated reliably and rolled back in case of problems should not be ignored.
Best Answer
Errr... sorry, this isn't how a DVCS (with a D as "Distributed") works at all.
a/ you don't "checkout" a file (like you would in ClearCase for instance). You just start modifying it, and Git will detect the change as a candidate for indexing (
git add) and for committing (git commit, the "checking" part)b/ When you "checkout" (i.e. modify) or checking a file, the other developers, with their associated other repos, don't know anything about that.
You "locking" everybody in that everybody can't access your repo and modify your files.
But when you publish (i.e push those changes), then you need to solve any concurrent modification. In a DVCS, there is no central referential able to detect a concurrent change and/or to record a "lock".