subversion最佳实践,将分支合并到主干,其中分支中的文件结构已被修改

时间:2012-01-24 00:39:11

标签: svn version-control tortoisesvn svn-repository

我面临的情况是我的开发团队想要重新组织我们的存储库中的文件结构。这个过程大约需要2-3个月。在文件重组过程中,我们仍然需要进行软件发布。因此,在重组过程之后,我们希望将分支中的有组织文件合并回主干。保留文件历史记录非常重要,而且我们需要能够在首次创建分支时合并trunk中的代码更改。

我最初的尝试是创建一个分支,然后简单地合并它。不幸的是,它并不像我想象的那么简单。我的一个测试场景如下:

  1. 从主干
  2. 创建分支
  3. 在trunk中更新文件
  4. 在分支中移动文件
  5. 更新分支中的文件
  6. 执行从分支到主干的合并
  7. 在第5步,我在trunk中更新的文件中出现“树冲突”错误。 TortoiseSVN不提供有关冲突文件所涉及的分支中的哪个文件的信息。在我的场景中,找出有问题的文件并不困难;但是,在我们的真实存储库中,它将非常困难,因为我们有数千个文件,其中许多文件具有相同的文件名(在不同的文件夹中)。

    有没有人遇到过和我一样的经历?我应该/可以做的任何建议/最佳实践,以确保代码的完整性?

    感谢所有帮助。

2 个答案:

答案 0 :(得分:2)

你可以采取两种方式

<强> 1。纯SVN方法

在合并 /branches/branchname /trunk 目录后重构从分支合并所有重命名/移动的文件与他们的主干原件,即/branches/branchname/some/branchfile1 /trunk/trunkfile1 ...和在最后一步合并dirs

<强> 2。 DVCS方法

使用任何具有良好合并的DVCS(他们都有它 - Git,Mercurial,Bazaar ......)和svn-bridge(git-svn,hgsubversion ......),执行重构合并在DVCS镜像的回购。毕竟 - 使用DVCS工具(... rebase)线性化存储库(SVN历史记录,DVCS -DAG)并将结果推送到SVN-repo。如果rebase对你来说太难了,你可以将最终结果从DVCS-of-choice(对于SVN背景我会考虑Mercurial或Bazaar,而不是Git)导出到无版本树中,然后只做单向同步WC用这棵树

答案 1 :(得分:2)

这就是我最终做的事情: 1.合并分支中所有重命名和修改的文件以及来自主干的所有更新(如果适用) 2.将分支提交到存储库。该分支现在具有最新的代码,包括自首次创建分支以来干线的更改 3.将分支中的所有更改合并回主干。 Trunk不会拥有所有更新的文件结构以及在trunk和重组分支中发生的所有更改

注意:对于在trunk中更新并移动到分支中其他位置的文件,预计仍会出现Tree冲突。我需要做的就是删除这些文件。

步骤#1是一个繁琐的过程,但它适用于我的测试。 这可能不是最好的解决方案,但它适用于我(维护来自主干和分支的更新,并保留历史记录)。