关于Unity和Plastic SCM协作的坑
Unity原生支持Plastic SCM，给广大开发者提供了全新的版本控制思路，相比Git、Perforce或者SVN等传统版本控制软件，Plastic SCM更像是为游戏开发而设计的，Unity选择这款产品，显然也是有它的道理。关于什么是Plastic SCM，可以参看官方介绍
近日开荒了用Plastic SCM来做版本管理，发现一些问题记录一下：
优势：
[*]可以直接在Unity编辑器中使用，不用离开当前工作环境。
[*]Unity为每一位开发者提供了免费的云端存储，无需自行架设服务器。
[*]操作速度非常快，虽然Git的本地commit也可以有这么快的速度，但是push和pull的时候就没有那么省心了。比起SVN那是快太多了。
不足：
[*]默认情况下只能在Unity编辑器中使用，Unity未提供独立工作模块的安装，用户得自行摸索使用方法。
[*]云端存储的方式还是为项目资产的安全和保护带来了隐患。
[*]开发者无法自行维护服务器端，无法按照团队需求来指定目录权限，还是带来了很多不便。基本只适合个人开发者和极小的独立游戏团队。
[*]只能在Unity工程中使用，开发者无法统一维护策划、美术、源码、工具等资产的版本控制，这一点比较致命，把所有项目资产全部放在Unity工程目录中这在实际开发中几乎是不可行的。
关于Plastic SCM对比其它版本控制软件的优劣，官方文档中写得很详细，这里就不在一一赘述 了。
接下来主要记录一个坑，这应该是Unity自身的逻辑漏洞，希望在未来的版本更新中能够被修复：
当我尝试自行安装Plastic SCM的企业版，并自行部署服务器端配置后台权限等设置，然后开开心心地建立起了适合实际项目需求的目录结构和权限分配，随后打开Unity想测试一下却发现Unity启动不了了。
ProjectBrowser.Repaint任务进入无限Hold on
经过反反复复折腾和尝试，终于发现问题原因，Unity应该是通过向Plastic SCM查询当前工程所在目录是否为Plastic SCM的Workspace并进行API的交互来更新Unity自己的界面的，当我们把Unity工程目录放置在一个Unity不能识别目录结构的Plastic SCM的Workspace中的时候，Unity就进入了无限Hold on，个人认为这是Unity的Bug，望修复。
Workspaces页签和Workspace Explorer页签
目前研究下来，找到的规避方法是，在Plastic的客户端GUI的Workspaces页签中手动Delete我们的Unity项目所在的Workspace，这并不会影响我们的实际工作，只是告诉Plastic SCM这个目录现在不需要你来监管了。然后再打开Unity就一切正常了。此时再在Plastic的客户端GUI的Workspaces页签中手动Create new workspace，选择本地的工作目录来关联到服务器端的仓库地址，这样Plastic SCM就会重新开始监管这个目录，此时激活这个workspace然后切换到Workspace Explorer页签，点击Update workspace，这样，一切就恢复正常了，Unity也能继续正常工作。虽然麻烦（坑爹）了一点，但是好歹能用。
Update workspace按钮
希望Unity官方了解到这个坑能进行修复，否则要想推广普及Plastic SCM怕是有些难度，尽管它毫无疑问是个好东西。 事实上，你可以自己新建一个目录，并将plastic的工程文件放进去，再在里面新建Unity项目，不需要在Unity里面安装plastic 为啥我已经安装了Plastic，但每次unity还是提示我得安装？ 事实是，这坑爹bug到现在一年了，还在！
unity的这个scm问题多到爆炸，根本不是一两个bug这么简单，一堆bug根本不修复
一堆没有测试过的版本就直接发出来，真的佩服他们的工程师，应该没有项目经理这个职位，完全惨不忍睹 非常感谢，终于把这逼东西关掉了 兄弟，我想问一下plastic scm怎么打开啊，我找不到它的安装位置了
页:
[1]