subversion 主干和分支 合并问题

subversion 主干和分支 合并问题

一直不知道主干和分支在SVN中的作用
今天公司项目组的成员用到了 而且遇到了主干和分支合并的问题
其实都知道subversion的eclipse差距subclipse支持主干与分支的合并
但就是很不安全 很容易覆盖掉文件

真实案例：
主干上是和服务器上部署的代码一致的
分支上是现有正在开发解决新需求的

可是在业务部门运营项目时，发现一个很急的bug需要处理
很显然 我们会创建一个分支进行修改，
等功能全部测试通过了 再合并到主干

这样主干上的代码就和正在开发解决新需求的代码都有改动
不能用最新的分支版本来合并最新的主干版本

应该用主干的前一个版本 和创建开发解决新需求的新分支时候是一致的
就可以用分支来合并主干

注意： 还是很不安全 需要确保每次按功能来提交版本 保存版本的

==
1、如果是需要将主线的改动合并到分支上，需要在分支的工作副本下进行合并，合并的范围是需要从主线上上次合并的版本到当前主线上最新的版本，如果主线和分支都修改了相同的文件，合并后会出现冲突，然后解决冲突，如果主线修改但是分支没有修改，则主线上合并的变更内容会增加到当前副本中，提交，如果是第一次合并，则起始版本号是上次建立分支的版本号
2、相反，如果是需要将分支的改动合并到主线上，需要在主线的工作副本下进行合并，合并的范围是需要从分支上上次合并的版本到当前分支上最新的版本，合并后会出现冲突（冲突的前提如上种情况），然后解决冲突，提交，如果是第一次合并，则起始版本号是上次建立分支的版本号

合并的工作是把主线或者分支上合并范围内的所有改动列出，并对比当前副本的内容，由合并者手工修改冲突。如果当前工作副本是主线的，则合并的范围是分支上的改动，如果工作副本是分支的，则合并范围是主线上的改动

如果主干上修改的，跟分支上修改的相同文件都比较多，那么，合并时就得一个个文件进行合并。这工作量不大吗？如果是多分支呢？

一直在想解决这个工作量的问题。

人眼检查后合并吧

你那个紧急分支上线成功后，除了要合并到主干，还要合并到其它正在开发的分支。

ps：紧急分支应该是从上一个生产版本建出来的。

而且也不存在“主干上的代码就和正在开发解决新需求的代码都有改动，不能用最新的分支版本来合并最新的主干版本 ”的问题。
都有改动一样可以合并，有冲突就解决冲突呗。

只有两个地方改了同一行，才会出现真正的冲突，否则svn都可以自动帮你合并了，
怎么会有很大工作量？

确实可以帮助你来合并
关键是解决冲突的效益问题
如果能够有个较好的方式或者管理上一贯执行的准则 可能效益会跟高些
最原始的 可能是自己记录那些是自己改过的 还有就是处理些什么问题 一一记录下来
方便上线前的 代码合并检查

记录下来 ？ svn的记录还不够么？

主干上修改了n多行，而分支又修改了n多行，假如我又再多一个分支又修改了n多行。你确保自动合并安全，可靠吗？！

自动合并只能保证代码不会被无意的覆盖、丢失。
安全可靠？
这么说吧，就算没有分支、合并，你确保程序员改的n多行代码安全可靠吗？

一个branch的生命周期要尽量短，如果一个branch的生命周期能够超过1周，那么首先要考虑一下你们的开发流程是否完善。

交叉merge永远都会带来各种各样的问题，请谨慎用之。merge过程中的人工干预基本上是不可少的，幸好现在工具很多，不用为此担心。