Unity's Source Code Control System Bug

You can stop banging your head against the wall because you've had to revert for the 8th time this week. Your co-worker, remote development group, or whomever it is that keeps overwriting your code is actually not at fault (well, most probably not at fault). We have confirmed that at least three other dev firms are running into issues with 2.6's SVN support.

If any representative from Unity is listening, pretty pretty please patch this bug!

Here's the update that I received from our CTO:

"I interviewed someone yesterday who said he ran into exactly the same problem that we did. Even more telling, I had a phone conversation with someone at a game development studio called ******* (they did *******, among other games; there are approximately 60 employees there) and they have not only run into this same problem (although in their case it was using Unity with Perforce) but also, in conversations with Unity about the issue, were told that Unity is working on fixing the problem."

I can't find any public comment from Unity on the Bug... Anyone?

Problems with the Lock-Modify-Unlock Solution

As I investigated TortoiseSVN for the first time, I came across their explanation as to why they prefer the Copy-Modify-Merge Solution over Lock-Modify-Unlock. Here's what they had to say:

Courtesy of TortoiseSVN help files:

Consider this scenario: suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost - or at least missing from the latest version of the file - and probably by accident. This is definitely a situation we want to avoid!


The Lock-Modify-Unlock Solution
Many version control systems use a lock-modify-unlock model to address this problem, which is a very simple solution. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.

Figure 2.3. The Lock-Modify-Unlock Solution





The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:

Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.

Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.

Locking may create a false sense of security. Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changes made to each are semantically incompatible. Suddenly A and B don't work together anymore. The locking system was powerless to prevent the problem - yet it somehow provided a sense of false security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.

It's common sense but a nice reminder as to why a merge solution is superior. You can read about their explanation of the Copy-Modify-Merge Solution here.