You'd think with a name like "Unity" it would be easier to use on a team. I've heard people complain about Unity's source control capabilities before but always assumed they were solvable if we used something external that had binary file locking, like SVN or Perforce. (Or even SourceSafe, shudder.)
Once I tried to synchronize work with Paul, though, I realized it's not so simple. Turns out that Unity doesn't respect the read-only flags on your files. So even if your source control package sets your binary files to read-only while someone else has them locked/checked-out ... Unity will let you go ahead and modify the files anyway.
The read-only flag is how I've made sure team members don't bash each other's changes ever since we first used SourceSafe with Die By The Sword at Treyarch in 1999. Unity is the first tool I've used that doesn't seem to respect the flag.
Because of this, it seems like everyone I've talked to who uses Unity on a team has their own set of voodoo for dealing with this stuff, whether it's "whiteboard checkouts" or just living with the occasional collision.
So, after Googling and searching Unity forums and spaces for answers fruitlessly, I contacted them directly, and they sent me a plug-in. (EDIT: forgot to include the script. Here it is: RespectReadOnly.cs )
I haven't tried it with Unity Free but it partially works with Unity Pro. It's intended to be used with Unity Team, which is an additional $500 and out of my price range, where it will grey out things in the inspector you shouldn't be able to edit. But even without that, it won't write over readonly files and with a little modification (which I did) it will protect you.
So hopefully they'll work on this more and roll it out for those of us not using Team, because it seems weird to me that we should pay an additional $500 per seat for a single function. If you're using Unity with someone else, or plan to someday, please vote up the issue - I just used all my votes on it - so we can all work on a team easier sooner.
A System That More Or Less Works
In the interim, here's our source control policy and system. This is what we do, and you could do it too, or use it as a starting point. It took me a lot of trial and error to get here, so hopefully this will save other people some time.
I'm certain I spent more time working out our source control system than I actually would have spent redoing work after collisions between me and Paul. Whoops. But I've been a source control enthusiast ever since 1999; old habits die hard. By the sword.
Anyhow, my loss can be your gain.
We use Unity Pro. (This is such a good deal. You get so much: static batching - i.e. much faster render times; postprocessing effects; and more, all for $1500 / person. Even if you're just a hobbyist it seems worth it - hobbyist photographers spend more on their camera equipment, yeah?)
We use Edit->Project Settings->Editor->Mode->Meta Files and Asset Serialization->Force Text. This means we don't have to lock our prefabs. Our experiments with simultaneously editing prefabs on separate machines turned out great.
We put the RespectReadonly.cs file (below) in our Assets/Editor directory. That makes it go.
We use Unfuddle hosting and SVN. (We tried Assembla and Perforce, which was a tooth-grinding ordeal, and Assembla and SVN, which kept disconnecting in the middle of large checkins.) Under a gig Unfuddle is free, although we expect to hit that ceiling soon, and it almost never makes you have to think.
Because we've set External Source Control, we don't need to check in the Library directory. And none of the individual files (.sln, assemblies, etc) in the root directory need to be in source control - they get generated by Unity if needed.
So it helps to figure out how to ignore files with SVN. It's kind of tricky with vanilla command-line SVN, but SmartSVN on the Mac and TortoiseSVN on Windows have some built in extra stuff that makes it easier. (On SmartSVN you can right click on a folder and go to Properties->Ignore Patterns and ignore things like LightMap*, Library and .DS_Store. TortoiseSVN has tsvn:needs-lock.) We also don't bother adding the LightMap files. These are things we'll generate on a more as needed basis, and don't want to use up the depot space with them.
We set svn:needslock on our .Unity and binary files (.fbx, .dae, .jpg, etc). SmartSVN makes this easy - in Project->Settings->Locks set "needs lock" for binary files, and make Binary Files include *.Unity.
And then we could add and commit our files. (With SmartSVN, if you've forgotten to set "needs-lock", it's pretty easy to set a bunch of files en masse: set it to show files from subdirectories and filter on the extension you're looking for, select all, and set it.)
And once it was all in there, the hard part was over. We can now get the latest revision and work on things in Unity. If we're changing scene files and binary assets, we also Lock them so nobody else is working on them at the same time.
Even if we both need to work in the same scene at the same time, it's doable as long as one of us is only changing prefabs.
Hope this helps other people, so they don't waste as much time as I do. Good luck! And if you have any questions I'm happy to answer.
Side Note: Why Not GIT or Mercurial?
You may ask, "Hey, Jamie, why not use the new hotness?" I used Mercurial for sixty second shooter, and appreciate it, but (so far) GIT and Mercurial are not intended for file-locking, and file-locking is the number one reason I want source control right now.
Having a history of changes is nice. Being able to make tinier commits to a local repository that I then push to the master server would be nice, but is pretty far down on my priority list. Preventing Paul and myself from accidentally working on the same scene file simultaneously is huge.