问题标签 [svn-merge]

我有一个案例，我的分支代表一个新版本，其中有一个重构的数据层，但是所有错误修复都应用于主干。
我是否以相反的方式做某事，因为我遇到的所有文档仅涉及将分支合并回主干。
我仍然想保持版本分支和错误修复同步，如何轻松完成？
特别是如果由于版本分支对其目录层次结构和文件进行了许多更改而导致冲突。
在这种情况下，最佳实践究竟是什么？

我正在使用我不习惯的 svn 设置，我需要将新代码从一个分支合并到另一个分支。

主干文件夹中没有代码，所以我不知道是否应该将主干更新为代码并更新第二个分支，或者是否有办法将一个分支更新到另一个分支。我最后的手段是手动更新代码。

任何想法这里最好的路线是什么？我正在从终端做所有事情。

我目前正在尝试将分支中的一些更改合并回主干，分支中的更改会取消主干中每个项目的名称。所以为了简单起见，让我们说树干的根看起来像这样......

分支看起来像这样......

在分支中运行以下命令以使其进入当前状态...

在此之后，分支和主干中都发生了代码更改。现在我正在执行合并，在我的主干工作副本中，我使用 Tortoise SVN 进行合并，选择“重新集成分支”作为合并类型，并选择分支的路径作为“来自 URL”作为运行的结果这个我现在在我的工作副本中......

文件夹 company-name-* 被标记为删除，其他去品牌文件夹被标记为添加。问题是去品牌项目文件夹中的所有文件都没有与之关联的历史信息，并且在去品牌文件夹中不存在主干中发生的更糟糕的更改。考虑到使用 svn 命令行工具重命名文件夹，我认为 SVN 将足够智能，可以从主干中引入更改并在合并后保留历史记录。我收到的结果是预期的还是我应该执行合并的其他方式？

由于我的 SVN 存储库仍然使用 Subversion 1.4，因此我使用svnmerge.py进行合并跟踪。我有一个与主干保持同步的功能分支（svnmerge init在分支之后，然后不时地svnmerge merge）。

现在我想将分支重新集成回主干（这与 SVN 书中描述的情况相同）。

我怎样才能执行相当于svn merge --reintegrateusing svnmerge.py？

在 Subversion 1.6 中有没有办法使用日志、mergeinfo 等来确定何时使用 --reintegrate 选项完成合并？（这假设人们知道哪些提交是合并的结果。）

我们有一个分支 B1，它还不稳定，所以它不在主干中。但是我们想处理来自 B1 的更改，因此我们从 B1 创建了一个分支 B2。

所以 svn copy 是这样完成的

几天后，B1 将稳定下来，B1 将重新整合到主干。

现在，问题在于将 B2 合并到主干。我们是将B2重新整合回B1然后重新整合到trunk还是直接重新整合B1->trunk和B2->trunk？

我有一种情况，我分支了主干，在我的分支中进行了几天的开发工作后，其他人更改了主干中项目目录的名称。像这样：从 /Project/Directory/trunk/old_dir_name 到 /Project/Directory/trunk/new_dir_name

这给我带来了一系列问题（当然）。

查看他执行此操作时的日志条目，它显示的只是： Action Path Copy from path Revision Deleted /Project/Directory/trunk/old_dir_name added /Project/Directory/trunk/new_dir_name /Project/Directory/trunk/old_dir_name 12345

当我尝试将主干测试合并到我的分支中以便获得最新更新时，我在一个文件上遇到了冲突错误。如果我尝试对该文件的最新版本进行测试合并，我会得到：错误存储库永久移动到“.../！svn/bc/13649/Project/Directory/old_dir_name/trunk”。

我该如何解决这个问题，以便我可以根据需要使我的分支保持最新？

（如果重要，我们使用 TortoiseSVN 前端）。

我有一个长期运行的功能分支，需要合并回主干。但是我有一段时间要正确地使用咒语，我需要一点帮助。

我的功能分支的日志如下所示（我正在简化以使其更容易）：

所以我想我想做的是合并 100-120、130-150、170。我不认为我想合并 130 或 160，因为这些更改已经存在于两个地方，并且很可能会给我带来树冲突。

（对于那些想知道为什么我不使用“重新集成”功能的人，这是因为我的颠覆服务器仍然是 1.4，所以它没有那个功能，AFAIK。）

如果您有一个带有 svn:external 链接的目录（我们在工作中广泛使用），那么每当您在分支之间合并该目录时，目录中的每个文件都会获得一个新的 svn:merge-info 属性。

我猜这是因为外部链接没有被合并更改，所以 svn 将它计算为它自己的子树（与为什么 svn 合并没有更改的分支会导致未修改的文件修改 svn相关，但不是同一个问题:mergeinfo 属性）。

这导致实际更改被隐藏在所有合并信息属性更改中，从而使更改集变得很大并且几乎不可读。（我们有一个具有足够合并历史和外部的分支，合并一行更改可能会导致 500Kb 差异）。

到目前为止，我们唯一能做的就是在提交之前使用 svn:external 链接从子树中删除合并属性。这阻止了使用 --reintegrate 并且意味着如果它们发生我们无法跟踪真正的子树合并。

有没有人有更好的解决方案？

在预提交脚本中，是否有可能（如果有，如何）识别源自svn merge?

svnlook changed ...显示已更改的文件，但不区分合并和手动编辑。

理想情况下，我还想区分标准merge和merge --reintegrate.

背景：

我正在探索使用预提交挂钩来为我们的项目强制执行 SVN 使用策略的可能性。

其中一项政策规定，某些目录（如/trunk）不应直接修改，只能通过重新集成功能分支进行更改。因此，预提交脚本将拒绝对这些目录所做的所有更改，除了分支重新集成。

有任何想法吗？

更新：

我已经探索了这个svnlook命令，最接近的是检测和解析svn:mergeinfo对目录属性的更改。这种方法有一些缺点：

1. svnlook可以标记属性更改，但不能标记更改了哪个属性。proplist（需要与先前版本的差异）
2. 通过检查 中的更改svn:mergeinfo，可以检测到svn merge已运行。但是，无法确定提交是否纯粹是合并的结果。合并后手动进行的更改将不会被检测到。（相关文章：Diff transaction tree against another path/revision）