SVN的代码正确提交方法

也会让我们百思不得其解，甚至耽误项目进度，浪费程序员的心血和结晶。
   下面就我们在外事项目中使用SVN的经验简单做个说明。
   如何正确提交代码？
   可能很多人用过微软的VISUAL SOURCESAFE 或者 Team Foundation Server，就认为那还不简单，checkout/checkin 不就完了吗。孰不知


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


式更适合小团队工作，谁修改，谁加锁，提交后解锁。MERGE模式却是谁都可以修改，而后提交时通过比较和合并解决分歧。所以，大家要按


如下方式更新才能正确提交。
   常见情况是：假定项目名称是FAMS。
   (一) 用户张三CHECKOUT 了 FAMS的 revision 101，然后开始工作。
   (二）用户李四CHECKOUT 了 FAMS的 revision 101，然后开始工作。
   (三) 现在李四完成了工作，进行提交，SVN 版本号变为revision 102，一切OK.
   (四) 现在张三完成了工作，也要进行提交，由于其工作的基础版本（workingbase）是revision 101,这时SVN会提示版本已过期，需要先


更新(svn-update).但这时真正的问题就来了：
    注意SVN的机制是提交时合并，如果它发现服务器上文件版本比本地文件版本新，它会自动把服务器上的文件更新到本地，如果这个文件


李四从未改过，一切OK，更新就可以了。
    但是，如果李四也对此文件比如名字叫 fillform.java做了修改, 这又分三种情况：
     第一种情况：李四新增方法或内容，张三也是新增的内容，各不冲突，一切OK，SVN会自动合并。
     第二种情况：李四删除了部分代码，但服务器上此文件（张三提交的）此部分代码未动，而版本却比本地新，则SVN会自动把服务器上


此文件内容合并到本地李四的版本中，注意啊：它把李四正确的删除工作给反复了，这就是SVN这种增量合并机制导致的最大问题。
    正确方法是： 首先拷贝此文件到另一个临时目录，比如D:\TEMP，然后SVN-UPDATE此文件，第三步拷贝此文件回来，由于此时工作基础


版本已更新至revision101，则可以正常对比，修改。最后提交即可。
    第三种情况：如果SVN-UPDATE时发生了冲突（conflict），会产生三个文件：
    一个是.mine 本地版本，
    一个是.r101,你的工作基准版本，
    一个是.r102,服务器端的最新版本。
    则手工修改冲突，然后先SVN-resolved， 注意这是告诉SVN你已经解决了冲突。然后执行下一步SVN-COMMIT即提交，就可以把新代码更


新上去了。
    怎么样？说的还够清楚吧？
    这时，有读者会问，一个文件这样可以，那整个项目怎么办呢？特别是我怎么知道哪些文件改了呢？别急，这个办法是有滴。
    一种方法是利用SVN-check FOR modification .
    另一种方法是利用 SVN-show log。 在弹出的项目版本列表上选择最新的版本（注意你的工作基础版本会用黑体列示出来）然后在右键


菜单上选择 comparing working copy 就可以找到服务器上最新版本与你本地工作版本的所有不一致的文件了。然后对这些文件逐一处理，


提交即可。


     最后，一点提醒：注意你的代码全部提交后，一般是用SVN-CHECKOUT 重新下载一个新版本进行工作，这样能确保代码最新，而不是在


原WORKING COPY上继续工作。