eclipse总结-svn

svn插件和服务端版本对应

插件svn1.4.x对应 TortoiseSvn1.5.x

插件svn1.6.x对应TortoiseSvn 1.6.x

插件svn1.8.x对应TortoiseSvn 1.7.x

插件svn1.10.x对应TortoiseSvn 1.8.x

插件svn1.12.x对应TortoiseSvn 1.9.x

插件和TortoiseSvn版本

 

在github上可以看到版本要求

https://github.com/subclipse/subclipse/wiki

查看svn插件版本

如果是解压安装的插件

插件安装

在线：

 Help --> Install New Software

点击add

Name填subclipse 4.3.0（任意指定）

Location填https://dl.bintray.com/subclipse/releases/subclipse/4.3.0

勾选全部进行安装就行

 

离线：

下载需要的插件包：http://www.oschina.net/p/subclipse

也可以在这里下载：https://dl.bintray.com/subclipse/releases/subclipse/

github上有源码和文档：https://github.com/subclipse/subclipse

github的文档上也有写下载地址：

包里会有"plugins"和"features"两个文件夹

 

创建SVN连接

分别创建trunk、branches、tags：

将项目发布到SVN的trunk

与资源库进行同步（比较不同）：

这么多内容都是应该提交到SVN的吗？

不是的，对于Maven项目而言，只提交src和pom.xml即可。

提交pom.xml

每次执行与资源库同步时都会有以上内容，会影响每次提交的选择，所以可以选择将这些目录文件忽略掉。

 

忽略指定的资源

全局指定

Windows -> Preferences -> Team -> Ignored Resources

或者在eclipse中，右键点击项目根目录 Team -> Set Property ... 然后在弹出的对话框中，Property name 选 “svn:ignore”，Property Content 输入：

target

.project

.classpath

.settings

就ok了。完了进入你的 SVN 的repository 里把已经commit进去的target目录和这两个文件(.classpath .project) 删除就可以了。

单个指定

删除忽略：

提交代码

当我们在本地将代码修改后需要提交到SVN仓库，以便别人可以获取到最新的代码。

注意：不建议直接提交，因为该文件可能会被其他人修改，从而造成冲突，推荐在提交（更新）之前先执行与资源库同步。

 

查看修改日志

更新代码

为了演示效果，在桌面将itcast-mybatis项目检出（check out），并且修改其中的文件完成提交。

可以双击文件查看差异：

然后，在Eclipse中将项目与资源库同步：

冲突解决（难点亦是重点）

什么是冲突？

 

冲突就是在同一个版本基础之上，多个人对该文件修改了修改，其中一个人将文件提交到SVN，这时，该文件已经是新的版本，但是，其他人的本地还是旧的版本，

这时，其他人并不知道该文件已经有了新的版本，执行提交操作，这时就产生了冲突。

 

解决冲突的核心思想：为了避免冲突，要在最新的版本之上修改（也就是说修改之前先更新），再提交。

 

如果我更新了之后，在编写代码的同时别人将该文件再次更新（我不可能时时刻刻都查看更新），这时直接提交会造成冲突，正确的做法是：提交之前将该文件先执行与资源库同步操作，先将冲突解决掉再提交代码。

 

接下来就需要讨论下个话题了，如何解决冲突？

 

首先要先明确，解决冲突是不能通过工具自动完成的，必须人工完成，当然了，可以借助工具辅助完成。

 

下面，演示冲突的解决过程：

制造冲突

在Eclipse中将文件内容修改，用于模拟用户1修改文件：

然后，在桌面中的目录中修改该文件，用于模拟用户2修改文件：

这时，先将桌面中的文件提交

提交成功。

在Eclipse中将项目与资源库同步：

解决冲突

分支合并主干的冲突解决

若存在冲突解决办法，个人建议使用最后一种解决冲突

Mark as conflicted. I will deal wiht it later. --标记冲突，合并到主干解决冲突

Resolve the conflict by using my version of the file.  --直接用主干的文件覆盖，分支修改无效

Resolve the conflict by using the incoming of the file. --直接用分支修改覆盖主干，以分支为准

Let me edit the file  with conflict markers inserted. --直接编辑冲突，编辑完保存，选择yes保存。

Launch a graphical conflict  resolution editor.--直接比对文件，修改冲突，点击保存。选择yes解决冲突

双击打开该文件，查看冲突的内容

将远程更新的内容写到本地

将该文件标记为合并（注意，一定是已经处理完冲突了才能标记，要不然会将服务端的文件覆盖掉）

现在，就可以大胆的提交了

冲突的另一种解决方案

有些时候可能会是这种情况：

 

服务端文件的内容被大量的修改，如果按照上面的方法一个个解决，非常的麻烦，这时你可以尝试以下的解决方案：

 

• 备份本地的文件

将该文件执行 还原 操作，并且再执行 更新 操作（也就说，放弃自己的修改，更新到最新的版本）

• 将备份文件中修改的内容，拷贝（不是全部啊，只是自己修改的部分内容）回该文件，再执行提交就OK了。

总结：这种解决方案的核心思想是，放弃自己的修改，把本地文件更新到最新版本，在最新版本基础之上修改，并且提交。

版本回退

查看历史记录--Switch to Revision 切换到指定的版本

这样只能查看那个版本的内容，不能提交

点击从修订版111111回复更改，然后提交就可以恢复到111111版本