我有一个我的行李箱的功能分支,并定期将我的行李箱的变化合并到我的分支机构中,一切正常.今天我将分支合并回到主干中,在创建分支后添加到主干的任何文件都被标记为"树冲突".有没有办法在将来避免这种情况？
我不认为这些被正确标记.
我经常读到Hg(和Git和......)在合并方面比SVN更好但是我从未见过Hg/Git可以合并SVN失败的地方(或者SVN需要人工干预的地方)的实际例子.您可以发布一些分支/修改/提交/ ....-操作的逐步列表,显示SVN在Hg/Git愉快地移动时会失败的位置吗？实用,非常特殊的情况请...
一些背景:我们有几十个开发人员在使用SVN进行项目,每个项目(或一组类似项目)都在自己的存储库中.我们知道如何应用发布和功能分支,所以我们不会经常遇到问题(即,我们一直在那里,但我们已经学会克服Joel的问题 "一个程序员给整个团队造成创伤"或"需要六个开发人员两周才能重新整合分支机构").我们的发布分支非常稳定,仅用于应用错误修正.我们的中继线应该足够稳定,能够在一周内创建发布.我们还有一些开发人员或开发人员可以使用的功能分支.是的,它们在重新集成后被删除,因此它们不会使存储库混乱.;)
所以我仍然试图找到Hg/Git优于SVN的优势.我很想获得一些实践经验,但目前还没有任何我们可以移动到汞/ GIT中还没有更大的项目,所以我坚持用只含有少量由文件小型人工玩的项目.而且我正在寻找一些你可以感受到Hg/Git令人印象深刻的力量的案例,因为到目前为止我经常读到它们但却未能自己找到它们.
当分支重新集成到主干时,该分支是否有效死亡？
重新集成后可以对分支进行修改,并在以后将它们合并到主干中吗？
我怀疑我有腐败的mergeinfo,但我不确定.有谁知道我如何做出决定以及有哪些资源来帮助解决问题？
这是问题所在.我的团队最近转向敏捷并使用功能分支(真正的故事分支),其中不同的团队同时处理相同的源.随着故事达到高度准备状态,团队合并到主干.由于缺少更改,意外更改和冲突,合并需要数天或数周.我们正在谈论5-10人的团队,努力/流失似乎很高.
人们使用这种合并模式a)PULL - 合并trunk到分支,解析,测试,提交b)PUSH - 合并分支到trunk,解析,测试,提交c)重新创建分支(或者通常创建新的故事分支和因为它已经完成了
到此为止,树枝和树干应该对齐.
我们遇到的问题:
(1)不应该发生.从分支到主干的拉动应使两者同步,以便在主干上进行所有更改.分支到中继合并的变化是主干上发生的变化.因此,在第一次合并时,它们应该传播到分支但不会.这指向mergeinfo数据中的损坏,这将"隐藏"主干更改.
(2)不应该发生.SVN应该管理合并跟踪中的更改.这也表明mergeinfo数据中存在损坏
(3)不应该发生.这是在分支上添加新文件的情况.它应该显示为添加到trunk的新文件.这也表明合并信息数据中存在损坏.
(4)我认为这是一个SVN错误,我们无法解决这个问题.如果这是我们唯一的问题,我会很开心
我们目前在svn 1.5.x服务器上,客户端使用svn 1.6.x和svn + ssh进行连接.我们计划推出最新最好的SVN,因为一些修复可能会影响我们的问题.
不过,看起来我们的mergeinfo数据确实是错误的.
我有什么好的地方可以开始寻找吗？
我已经阅读了很多很多内容,但无法弄清楚问题是什么,而且非常奇怪.我正在为客户端使用1.7版本的服务器和最新的乌龟版本(1.7).这是场景:
嗯,当然目录在子分支中就像它最初来自的那样.我虽然svn 1.5+轨道使用merge-info合并,但应该知道这是目录来自的分支,不应该抛出树合并错误.
知道发生了什么,我该如何解决这个问题？我给出的示例仅适用于1个目录,但实际上有很多目录和文件,因此手动逐个进行需要数小时.