SVN代码正确提交方法

很多人用过微软的 Visual SourceSafe 或者 Team Foundation Server，认为很简单，checkout/checkin 不就完了吗。

孰不知由于SVN采用了另一种源代码管理机制(merge模式），而微软采用的是传统的(lock/unlock）机制，由于机制不同，提交方式也不同。

LOCK模式更适合小团队工作，谁修改，谁加锁，提交后解锁。

MERGE模式却是谁都可以修改，而后提交时通过比较和合并，遇到冲突则需要解决分歧。

所以，大家要按如下方式更新才能正确提交。

常见情况是：假定项目名称是 MIMVP

(一) 用户张三 checkout 了 MIMVP的 revision 101，然后开始工作。

(二）用户李四 checkout 了 MIMVP的 revision 101，然后开始工作。

(三) 现在李四完成了工作，进行提交，SVN 版本号变为revision 102，一切OK.

(四) 现在张三完成了工作，也要进行提交，由于其工作的基础版本（workingbase）是revision 101，这时SVN会提示版本已过期，需要先更新(svn-update).但这时真正的问题就来了：

注意SVN的机制是提交时合并，如果它发现服务器上文件版本比本地文件版本新，它会自动把服务器上的文件更新到本地，如果这个文件李四从未改过，一切OK，更新就可以了。

但是，如果李四也对此文件比如名字叫 fillform.java做了修改，这又分三种情况：

第一种情况：新增内容

李四新增方法或内容，张三也是新增的内容，各不冲突，一切OK，SVN会自动合并。

第二种情况：删除内容

李四删除了部分代码，但服务器上此文件（张三提交的）此部分代码未动，而版本却比本地新，则SVN会自动把服务器上此文件内容合并到本地李四的版本中，注意：它把李四正确的删除工作给恢复了，这就是SVN这种增量合并机制导致的最大问题。

正确方法是：首先拷贝此文件到另一个临时目录，比如D:\TEMP，然后 svn up 此文件，第三步拷贝此文件回来，由于此时工作基础版本已更新至revision101，则可以正常对比，修改，最后提交即可。

第三种情况：冲突内容

如果 svn up 时发生了冲突（conflict），会产生三个文件：

一个是.mine，本地版本，
一个是.r101，你的工作基准版本，
一个是.r102，服务器端的最新版本

则手工修改冲突，然后先 svn resolved，注意这是告诉SVN你已经解决了冲突。

然后执行下一步 svn commit 即提交，就可以把新代码更新上去了。

怎么样？说的还够清楚吧？

这时，有读者会问，一个文件这样可以，那整个项目怎么办呢？特别是我怎么知道哪些文件改了呢？别急，这个办法是有滴。

一种方法是利用SVN-check FOR modification .

另一种方法是利用 SVN-show log。在弹出的项目版本列表上选择最新的版本（注意你的工作基础版本会用黑体列示出来）然后在右键菜单上选择 comparing working copy 就可以找到服务器上最新版本与你本地工作版本的所有不一致的文件了。然后对这些文件逐一处理，提交即可。

最后注意

你的代码全部提交后，一般是用 svn checkout 下载一份新版本代码到本地进行工作，这样能确保本地个代码最新，而不是在原WORKING COPY上继续工作。

参考推荐：

Most Valuable Package of Mobile Internet