第二个问题是关于SVN使用的。
svn项目目录下有一个database文件夹， 里面放着sql脚本、ER图和数据字典。当分配到任务的人需了解数据库表格信息时，看sql脚本的人不多，大部分人在大部分情况下都是看数据字典。没有加权限控制时，查看的人多了， 乱子也就出来了。
刚使用svn，我（作为一个管理者）一开始并不知道权限控制， 只会导入工程、 提交和更新。从理论上来讲， 数据库是只允许我一个人更改的， 别人若有需要修改数据库， 要告诉我后再由我来修改。 我改完脚本后顺便也会改一改数据字典， 然后提交。 所有表格都要有一个status字段， 用来标识记录是处于正常状态还是已经被“删除”， 如0表示正常， -1表示已删除。所有的删除操作都只是改变记录的status值，这样做的好处是可以恢复已被用户“删除”的记录， 为用户提供一剂后悔药。这是我们在建好数据库表格后老师跟我们说的，所以需要在项目开始后改动。这个改动给我留下非常深刻的印象， 因为在两天之内我改了不下三次。 第一次改完后，提交， 然后， 被人用旧版本覆盖。 第二次改完，提交，然后给大家提了个醒，可没过几个小时又被人覆盖。 第三次我怒了，得了俩教训， 第一个是改完后要留个备份， 省得被人覆盖后还要再重改原来的文件； 第二个是权限控制。在网上找到方法后，我把整个database文件夹的权限设为只有我自己可以读和写， 其他人都只有可读权限。
这只是文件被错误覆盖的一个例子，在刚开始的两三天，这种事情多次发生。 对database文件夹我可以加权限， 可其他的文件夹呢？
我想了想为什么会发生这种情况， 还是以数据字典为例。 数据字典是一个word文档， 在查看时文件时不小心打个空格或拖动某个字符是很平常的事。 关闭并保存文件后， SVN会认为这个文件已经更改过。 由于大家刚接触SVN，不怎么会用。在提交文件时经常有人会将整个工程提交， 假设这个人为B。 照理来说， SVN有版本控制机制可以防止覆盖的发生。当我成功提交更改好的数据字典后，B会由于版本冲突不能提交。 如果B更新一下的话， 会多出三个文件， 文件名是在原来的文件名上加上新的后缀（我只记得有一个是以.mine结尾）加上原来的doc文件就有四个文件了，必须删掉四个中的三个才能提交，如果不懂的话， 一般会删除非doc后缀的文件，然后提交。如果是文本文件（.xml, .java, .jsp）发生版本冲突， 后缀名不变的文件会是SVN自动合并的文件， 但doc文件是二进制文件， SVN不能合并, 所以以doc结尾的文件是以前的旧版本文件。当B提交这个旧版本后， 我之前提交的就被覆盖掉了。(个人不想相信这个猜测， 因为这种人也太二了点， 也许还有其他更高级的覆盖方法...）
好在只是在头三天常这样， 到目前， 已经很少有错误覆盖的事情发生了。原因有三：覆盖频率最高的database文件夹已经加了权限控制；第二，经过多日的使用，大家已经比较熟悉SVN的基本使用， 再加上多次提醒不要提交整个工程、要选择性地提交自己改过的文件后， 很少有人再犯这样的错了， 都小心翼翼的。
还有， 我想， 若是在一开始按功能模块分工， 错误覆盖的发生率应该会降低， 因为不同的模块对应不同的文件目录， 两人同时改一个文件的概率会很小。
1 楼 timelyRain 昨天
还有另一种办法，使用svn的lock功能，可以避免二进制文件并发修改后出现冲突
去谷歌关键字 svn:needs-lock
去谷歌关键字 svn:needs-lock
2 楼 westmoon 昨天
1楼说的对，sourcesafe这种lock模式更适合避免这种情况，不过不乱保存和提交自己不确认的改动是开发的基本素质，吃一堑长一智吧