SVN代码管理使用方法和注意事项

使用SVN最主要遇到的问题：

想必大家现在都比较喜欢使用svn(subversion)完成代码管理了，因为它的开源，轻巧，易用。但是这样一个宝贝如果不知道其正确的用法，也会让我们百思不得其解，甚至耽误项目进度，浪费程序员的心血和结晶。
下面就我们在外事项目中使用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上继续工作。

GOOD LUCK!

转自：http://blog.sina.com.cn/s/blog_5920510a010128ax.html

下面是另一篇基本使用方法

SVN代码提交流程
前言：

经常从SVN上取最新代码下来后发现编译过不去，查找提交log找到之前提交的人，了解其提交代码的流程后，发现SVN代码提交流程有点问题. SVN代码提交虽然简单，但是如果没严格按照步骤来的话，很容易出错，出现代码覆盖，遗漏提交的情况。现在整理一个SVN提交代码流程的精简的版本。

有2种方法，推荐方法1。

方法1 通过本地SVN代码库中转提交：

1。本地SVN代码库更新

为了方便代码提交，建议本地维护一个与SVN对应的，只用来存放最新代码的本地SVN代码库（不做开发用）。其作用主要是用来在每次代码合并前，先从SVN上取最新代码。

（代码更新完毕后，如果修改不多，合并时间不会太长，则可以把代码库锁定：代码库文件夹右键--TortoiseSVN--Get lock...；如果修改太多，合并时间比较长，建议不要锁库）

2。合并本地开发库代码到本地SVN代码中

本地开发库代码可能是我们在一个月前，半个月前与SVN同步过，但是现在可能不一样了。我们现在要做的，是把本地开发库中的代码合并到前面1中的那个SVN代码库中去。

这里有一个非常重要的原则：合并代码的时候，我们只处理那些我们确认是我们自己新增的，修改的，删除的代码到本地SVN库中。任何不是我们做的修改，我们一律不要去动它。

比如有一段代码我们我们开发的时候没有，但是现在本地SVN库里有，那我们不要去删除它，而是忽视它，因为它应该是其他人新增上来的。

（说明：如果碰到修改冲突，这个不多，如果是遇到这个情况，应该考虑如何把我们的修改加入到最新代码上去）

3。编译本地SVN库代码

编译通过了才能提交到。这个可以防止提交遗漏，保证其他人从SVN上取下来的文件都可以编译通过。

4。合并本地SVN代码到服务器SVN代码库中

现在，我们本地SVN代码库中已经有了我们本地要提交的代码了。

如果我们之前有锁库了，则可以直接就把代码提交上去了（提交时记得写上日志，以便后面修改调阅）。

如果之前没锁库，这个时候还不能马上就提交了。因为这个时候可能其他人又提交代码了。所以，我们要先把这个代码与服务器SVN的代码再diff一下，以确保要提交的内容就是我们修改的内容。

说明：如果发现有变动，则重复上面1，2，3，4操作。

5。提交完毕

如果有锁库，则要进行解锁。

方法2 直接在开发库提交：

1。直接更新本地开发库代码

更新过程中，可能会发现不少提示冲突的。

更新完毕，如果修改不多，像上面方法1的1一样，可以把库锁定。

2。备份冲突

逐一找出提示冲突的那些文件（比如test.cpp），ctrl+c,ctrl+V一下（多出个 复件 test.cpp来），把test.cpp删掉

3。解决冲突

等把所有有冲突的文件备份过后，重新更新所有代码，这时那些有冲突的文件都将回到目前最新的版本中。

把备份的文件(复件 test.cpp)和目前最新文件test.cpp进行对比，把属于我们的修改的代码合并到test.cpp中去。当然，如果功能冲突，则要考虑我们的修该该做如何变动。

如果仅仅是修改位置冲突，则挪下位置就可以了。

4。编译代码

编译有问题则要进行修改。

5。提交代码

如果之前有锁库，则可以填上日志，直接提交。

如果没锁库，则在提交之前还要再diff一下，以确保要提交的内容都是我们自己修改的内容。

PS： 如果中间又有人做修改，则重复1，2，3，4，5操作。

6。提交完毕

如果有锁库，则要进行解锁。

方法1和方法2的比较：

方法1 通过本地SVN代码库中转提交

缺点: 浪费空间 

优点: 比较安全。比如我们在进行提交到服务器SVN代码库中，如果操作失误（冲突合并错了），没关系，重新从本地开发库合并到本地SVN中再进行比较提交。

方法2 直接在开发库提交

缺点: 1)比较危险。因为我们是直接对本地开发库进行操作，万一在提交过程中发现错误了（比如冲突合并错了或代码删错了），则可能就没的恢复了。 2)不容易发现提交遗漏的情况.因为编译的时候,由于是代码都在本地,不容易发现代码提交遗漏

优点: 提交比较快,不用通过中转

所以推荐使用方法1。

附注：一般，我们提交代码时，为了减少合并冲突，最好都在群里告知项目组其他同学我要提交代码了，这样别人可以有意避开

svn 更新 合并 提交的区别
别人告诉的 原文复制

当本地文件没有改动，服务器文件改动的时候，更新会从服务器取文件覆盖当前文件
当本地文件有改动，服务器文件没改动的话，不会更新此文件
当本地文件有改动，服务器文件有改动的话，如果改动的部分不冲突，就会合并文件到本地，如果有冲突的话，会提示文件冲突，需要自己手动修改以后上传到服务器

最后一个讲解合并：
服务器和本地的同一个文件（所谓同一个文件应该就是SVN相对路径相同，文件名相同的文件，这个由SVN留在本地的信息决定）已经修改，且修改的部分不重合，不重叠
当满足上面的条件的时候再更新，SVN就会自动合并

SVN的奥妙之处就在于别人提交了修改后的文件，你再提交你的话，他是不允许你提交滴。。。

>>>>
<<<
里面标记的是冲突的区域，把冲突区域删除掉为什么还不能提交

解决办法1：

删掉的话还是没有解决冲突，文件后面还会有几个文件名相同，但是后缀不同的文件
如果你不知道用SVN解决冲突的话，最简单的办法是这样的
把这个文件改名字，然后在文件所在目录更新，这样就会把服务器文件下下来，然后把自己修改的部分添加到更新的文件里面，这样就可以提交了

解决办法2：

在文件上面点击右键，到SVN的菜单，应该有编辑冲突的按钮，选择就会出现一个窗口，一边是服务器版本，一边是自己修改的版本

转自：http://blog.csdn.net/udking/article/details/6176924