1、忽略的文件：
target、.project、.classpath、.settings
将maven项目提交到svn时，应该避免将target目录及eclipse配置文件 (.project，.classpath，.settings)提交，因为这些文件都是可以从源代码和pom文件重新生成的,没有必要再进行版本控制， 如果提交到svn中反而容易引起冲突和不便。
2、博主现在正在实验室帮助资本主义干活，鉴于以前在实习的时候入过svn的坑，所以还是建议各位使用svn时候小心一些。
1、更新就是别人的代码提交过了，但是本地的代码没有变，需要你更新。使用命令是team->update更新
2、提交是指服务器上没有的，也就是你改过的东西，你需要将代码提交，使用命令是team->commit 提交
3、两个人同时修改了一个相同的文件，提交时会发生冲突，所以要先进行同步。
同步是在更新或者提交之前做的工作（切记一定要养成这个习惯，先同步一下看看是否有冲突），出现冲突不能提交也不能更新，只有先将冲突的文件解决才可以更新和提交。
同步：synchronize with repository (如果你的项目连了svn 右键你的项目 team…就能看到) 点击同步后会进入到synchronize 的界面。再右键项目就有
Mark as mergerd （标记为冲突， 冲突的文件会用本地的覆盖服务器的，意思就是说用你的！）
Override and update (覆盖或更新 选此项表示 用服务器的)
协商后双方代码都有时，点击更新出现如下代码：
<<<<<<< .mine <!-- workspace5提交代码 --> ======= <!-- workspace --> >>>>>>> .r9 代码修改后，删除产生的rar包，再次进行提交。
3、Eclipse Svn的分支与合并教程
使用分支的场景
1、要对某一个模块做重大调整，而不想别人打扰你或你不想打扰别人的工作，因为你修改的内容比较多，在没有完全改好并测试过之后就提交的话，别人更新后的程序就用不了了，
但是如果你一直不提交，等到你完全改好后再提交，那怎么体现svn的版本管理达到协同开发的作用呢？通过分支可以避免这个问题。
2、主干已经开发完成，要进行发布，那把主干复制到分支，然后分支主要进行bug的修改和完善，而主干继续进行新特性的开发。比如我们要对框架进行升级工作，我们在目前
的主干开发了差不多的时候，就可以准备发布1.0版本了，那我们把主干的复制到一个叫版本1的分支，在修复测试、发布1.0版本的同时，主干继续进行2.0的开发工作。
当分支有bug修复的时候，同步到主干。
主干用来存放稳定的代码，每个版本都会开一个分支，等版本完成后再合并到主干。版本一个一个迭代，但可以并行开发。
假如没有多版本并行开发，或者多部门协作开发，只有一个主版本的话，分支是没必要的。
主干保证是稳定的，有时候还要打tag来留作主干的备份
“主干永远是稳定的”，我还是无法接受这个观点：相对而言吧，这是贯彻的思想吧，尽可能保证主干的稳定
☆☆☆☆☆☆☆
If you’re afraid to fail then you’re probably going to fail.
如果你害怕失败，那意味着你已经输了。
—— 科比
☆☆☆☆☆☆☆
