TortoiseSVN 的使用

TortoiseSVN 的使用

http://www.cnblogs.com/qlee/archive/2011/03/19/1989030.html

svn代码冲突，不能提交的解决方法

http://www.blogjava.net/jasmine214--love/archive/2011/04/07/347769.html

详解SVN文件冲突和树冲突解决方法(转)

http://xafc2370.iteye.com/blog/1108440

当你从版本库更新、合并文件时，或者切换工作副本至一个不同的URL时你会遇到冲突。有两种冲突: 
SVN文件冲突 
当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。 
SVN树冲突 
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。 
SVN文件冲突 
当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于Subversion不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记: 
<<<<<<<文件名你的修改=======合并自版本库中的代码>>>>>>>版本 
对于每个冲突的文件Subversion在你的目录下放置了三个文件: 
文件名.ext.mine 
这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。 
文件名.ext.r旧版本 
这是在你更新你的工作副本之前的基础版本(BASErevision)文件。也就是说，它是在你做最后修改之前所检出的文件。 
文件名.ext.r新版本 
这个文件是当你更新你的工作副本时，你的Subversion客户端从服务器接收到的。这个文件对应于版本库中的最新版本。 
你可以通过TortoiseSVN→编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要指定哪些代码是需要的，做一些必要的修改然后保存。 
然后，执行命令TortoiseSVN→已解决并提交修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。 
如果你有二进制SVN文件冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到 filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。 
你可以右击父文件夹，选择TortoiseSVN→已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。 
树冲突 
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。 
当一个文件通过Subversion在本机删除后，文件也将从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。 
TortoiseSVN能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记:当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的状态，而不是你开始进行更改前的状态。 
本地删除，当更新时有更改进入开发人员A修改Foo.c并将其提交至版本库中 
开发人员B同时在他的工作副本中将文件Foo.c改名为Bar.c，或者仅仅是删除了Foo.c或它的父文件夹。 
更新开发人员B的工作副本会导致树冲突: 
在工作副本中，Foo.c被删除了，但是被标记为树冲突。 
如果冲突是由于更改文件名引起的而不是删除文件引起的，那么Bar.c被标记为添加，但是其中却不包括开发人员A修改的内容。 
开发人员B现在必须做出选择是否保留开发人员A的更改。在更改文件名的案例中，他可以将Foo.c的更改合并到改名后的文件Bar.c中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员A更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员A的更改。 
如果TortoiseSVN能够找到被改名为Bar.c的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。 
本地更改，当更新时有删除进入开发人员A将文件Foo.c改名为Bar.c并将其提交至版本库中。 
开发人员B在他的工作副本中修改文件Foo.c。或者在一个文件夹改名的案例中... 
开发人员A将父文件夹FooFolder改名为BarFolder并将其提交至版本库中。 
开发人员B在他的工作副本中修改文件Foo.c。 
更新开发人员B的工作副本会导致树冲突。对于一个简单的SVN文件冲突: 
Bar.c被当作一个正常文件添加到工作副本中。 
Foo.c被标记为添加(包括其历史记录)并且产生树冲突。 
对于一个文件夹冲突: 
BarFolder被当作一个正常文件夹添加到工作副本中。 
FooFolder被标记为添加(包括其历史记录)并且产生树冲突。 
Foo.c被标记为已修改。 
开发人员B现在需要做出决定是否接受开发人员A作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员A的更改并保留本地文件。 
要合并她的本机更改到新布局中，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。 
如果开发人员B认为A的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员A的更改。又是通过日志对话框帮助追踪哪些文件移动了。

以下抄子百度知道：

svn update 是不会覆盖你的更改的，如果别人的修改跟你的距离很远，svn 会将别人的更新合并到本地文件中，如果距离很近 svn 无法判断如何合并，会生成 .mine .r# .r#-1 原文件 共四个文件，供你选择保留哪些代码，处理后 reserved 一下，除了原文件以外就都删除了，commit 就可以了

在代码的编写过程中，难免有些错误需要修改，或者想从以前的文件进行代码修改，这样就涉及到版本的追踪，如果你以前提交时日志写的非常清楚，那版本追踪回滚起来就事半功倍、得心应手。下面介绍几种版本回滚的办法：1.推荐的一种方法是，直接export一个你需要的版本，然后用你export的版本覆盖你的最新的版本，这样你就可以不丢失你新建的文件，同时获得最新的SVN版本控制。操作步骤：TortoiseSVN→Show log→选中需要回滚的版本→右键→Export。之后将修改的文件覆盖到你的最新版本，commit即可。2. 若是你编辑了工程，在没有提交的前提下，你想放弃这些修改，你可以直接选择TortoiseSVN→revert就可以更新到工程的最新的版本。3. 若是你想退回到某一个版本，你就可以直接选择TortoiseSVN→update to reversion,这样我们就可以把我们的版本回退到你选中的版本去，这种情况下SVN并没有显示出有什么冲突，并且新建立的文件也还在，但是在这种情况下你并不能直接在你回退后的版本上进行编辑，因为SVN的版本控制还是在最新的主干上。我们需要update并解决冲突。 4.你可以直接选择revert changes from this revision，这样的话你可以直接解决冲突并提交。不过这种方法的不足是，你新建的文件都没有了，整个工程都回退到之前的版本了。5.可以从日志中回滚到你需要的版本，从日志中选中你需要的版本，然后Update item to reversion就好了，这种情况下SVN并没有显示出有什么冲突，并且新建立的文件也还在，但是在这种情况下你并不能直接在你回退后的版本上进行编辑，因为SVN的版本控制还是在最新的主干上。我们需要update并解决冲突。