A quick and dirty source control explanation:

The server has the One True Copy. You connect with your client and sync your local copy to the One True Copy. When you want to change something, you let the server know and you perform a "check out." Later when you are done, you commit or "check in" your change back to the server and update the One True Copy. When another developer wants to edit the same file you do, the server tells him "hey, someone else is editing that so watch out." If the One True Copy has changed from the version you had when you go to check in, you are warned and have to merge any conflicts you have.

The server keeps a full history of every change so you can roll back, branch, etc. Accidentally check in something that broke the build? No problem, just roll it back! No need to go to the tape drives and hope the version you want is there.

The problems you mentioned (lots of incompatible copies out there) are real. You need to ensure that people are checking in often and staying up to date. Going off for 2 weeks then coming back with tons of changes is a recipe for bad things.

Working off a file share like that is not a scenario for Visual Studio so it's unlikely that you'll see development effort from the VS team to enable it. They, as many here have, would reccomend using a source control system for managing multiple developers rather this set up.