U3DMakeStandaloneWindows64 是否仍然叫 U3DMake 好？
有以下命令：
这个方案的好处：
  1. 如果一个人只启动windows的客户端，则只需要svn co后，从U3DMakeStandaloneWindows64打出ab即可
  2. 一个工程目录能同时打3个平台的ab，能打开3个U3DMake的Unity编辑器分别进行编辑，3个目录都能分别svn ci
  3. 本地U3DMake目录同步只同步被SVN管理的资源文件和UI资源文件，不会一股脑的什么文件都同步。这样copy和svn up对所管理的文件是一样的。（本地临时添加和删除的文件需要本地先svn add或者svn del才能同步）
  4. 远程U3DMake目录同步只需要远程机器启动了IO工具和部署了客户端下载站点即可。其绝大部分工作流程和copy一样，最终的效果和copy一致。
  5. 比较绿色。无论工程目录svn co到哪里，都无需有额外的文件或者环境变量的配置。
  6. 这个目录结构能保证一个完整的EggN（忽略ZDocument）而不只是完整的Develop。这样ZTool目录也在工程中。
  7. 只需要写一个u3dupdate的脚本实现命令行支持。打多平台ab的源文件的管理逻辑全部再这一个地方，这样就无需多个地方写代码。
  8. 本地打ab，版本机打ab，其流程和所需参数都一致。
这个方案的缺点：
  1. U3DMake中的打包AB脚本需要能兼容下U3DMakeStandaloneWindows64、U3DMakeAndroid和U3DMakeiOS三中情况。我大概看了，只有少许几个地方要改。这样改为后，都在一个工程目录下，打包出来的ab就直接在指定的地方了。
  2. 对于版本机，在打包手机的ab的时候会额外up下U3DMakeStandaloneWindows64，但是打ab的时候又用不到。
  3. 如果同时的隔离的开发windows下和android下的Client目录，则需要另外svn co一个目录来搞，而旧方案恰好为每个操作系统提供了Client。但是如果是同时的隔离的开发windows下的Client和U3DMake，则新旧方案都需要额外的再svn co一个工作目录。
  4. Client目录需要切换不同的操作系统