吐槽一下，公司的权限给的很死，部署的时候麻烦事比较多，趁手的工具需要自己手动编译，无法利用port安装。
昨天遇到一个外服部署的问题，表现为外服不能登陆，用部署工具重新发布代码后，仍然如此。于是联系运维的同学进行处理，运维的同学帮助排障时发现引擎启动报错，提示rc/simul_efun must be loadable，认为是代码的问题。回去检查代码后，没有发现问题，而且这个文件已经很长时间没有更改了，怀疑是编译的问题。后来，手动连接外服，将验证服务器跑起来了，但是游戏服依然提示同样的错误。最后通过备份代码，然后用验证服的代码加游戏服的配置启动成功。但是，对于这个错误还是很耿耿于怀，于是找公司的前辈帮忙排错，发现发布代码的过程里漏了一个关键的步骤，补上后似乎没有问题了。
今天回想一下，感觉下次还是有机会出现上述的问题。首先，是引擎的报错太具有误导性，如果是代码缺失，就应该提示文件不存在或代码缺失，而不是代码有错误。（究竟是不是代码的问题，周一回去以后还要再次确认）其次，是我发布的时候粗心大意，这个应该通过更傻瓜化的工具解决，内网发布时我已经写了点bash脚本进行一键发布了，但是外服运行环境不同，还需要修改一下。再次，是发布工具的效率问题，一个是提示信息含糊不清，第二个是杀进程时只会sleep等待，不会主动监控进程运行状态。
关于外服内服环境不同，这个还要再吐槽一下。外服上运行的是9.0的Freebsd，内部测试服则是8.2的，内部测试服同时兼任打包服务器、发布服务器的角色。在9.0的系统上编译得到的引擎，无法在8.2的系统上面运行。而指定发布机器时，外服和内服又是同一个标签之下的，也就是说，更新外服的话内服的引擎版本就错了，内服更新时，外服的引擎版本也会错。这个问题已经足够致命了，更致命的是打包发布脚本提示信息是可以通过hostnum指定机器的，但实际上却不可以，真让人抓狂。以后打算把游戏逻辑的svn版本和引擎代码的svn版本都打包到代码里面，可以在运行时查询，否则发布脚本的错误会导致大问题。
另外，公司的svn服务器证书过期，最近一段时间至少引起了3次问题，主要是策划利用热更新通过svn拉取数据表更新时出现。因为svn密码不允许明文保存，所以设置了store-passwords = no。面对证书问题，会出现拒绝，暂时接受，永久接受。选择永久接受后，就一直出现svn: E175002: Unable to connect to a repository at URL，但是证书错误的原因反而没有提示。干掉~/.subversion 目录后，再次出现证书的问题，每次选择暂时接受就可以正常checkout了。store-password选项影响到subversion对证书的选择，好奇怪