We use git to share our Unity-free scene, and it works reasonably well. (git terminology -- clone = make new local copy of repository, pull = sync down latest changes, commit = check in locally, push = post your local commits to the shared repository).
You do need to be a little careful to make this work. Here's how we do it ...
First of all, our folder structure is:
(projectroot)
\ml
\Code
\Art
\Editor
\scene-ml
\Assets --> (projectroot)\ml
\Library
\Scenes
"ml" is our mainline git repository for code, art, etc. This repository is treated just like normal version control -- edit, commit, merge, etc. and push to origin when you want to share with the rest of the team.
"scene-ml" is a second git repository for our scene. This repository is treated as unmergeable -- only one person at a time can make changes that they plan to push out the rest of the team. Under the scene-ml folder, the Assets folder is a symbolic link to the "ml" repository. (See the Windows 7 mklink /D command to create symlinks.)
For day-to-day development, we clone a copy of the scene-ml repository to a scene-local folder. Changes made here are never pushed back to the shared mainline, but can be committed locally for testing.
Git is nice and flexible for pulling down multiple copies of repositories to different local folders, so if I want to see the latest stuff from everyone else I can pull it down as a copy without disrupting my local work in progress.
When you want to share scene changes with the team, you need to update your ml (to get the latest code and art), then delete scene-ml and re-clone, to make sure you have the latest scene. Then make your changes, commit everything back to scene-ml, and push back to the shared repository. We commit everything under the root folder, including Library\cache, etc. After cloning the scene repository, next time you start Unity it will reimport all the assets, which can take a while, depending on your data. If you're worried about having one git repository inside another (the Assets folder points to the ml repository), don't -- git is clever enough not to include the nested repository.
You don't have to use git -- you would get the same effect by zipping up your whole scene folder and posting it to shared storage somewhere. The useful trick we've come up with is putting code and art into a separate (version-controlled) repository and using symlinks to connect these assets to the scene. To do this with zip files you would want to delete the symlink before zipping and posting, then recreate the link when you unzip.
We're using codebaseHQ for our git hosting, a nice cheap solution that has worked well for us so far. We also use the codebaseHQ ticketing system to keep track of who's working on the scene -- ticket #1 is "I OWN THE MASTER SCENE" and always left in status "New". You assign it to yourself when you're making scene changes, then unassign once your changes are pushed to the team.
Caveat: our development is still in its infancy, so we don't have a ton of code, art, big scenes, or a large team. Your mileage may vary! Questions welcome if you want to know more.