相关疑难解决方法(0)

我最近在干线上工作,我做了改变,我认为其他人可能需要它们,所以我在提交之前创建了一个补丁.

现在,一个正在开发分支的开发人员(几周后来自主干)需要将这些更改发送到新的服务器上.

我正在尝试使用Tortoise SVN应用我的补丁,但它并不像我的工作副本的差异.我有 :

• 我的主干在:D:\ SVN\Trunk
• 分支在:D:\ SVN\Branches\TheBranchINeedToPatch

我想做一些不可能的事吗？有什么我想念的吗？

我可以将树干补丁应用到分支工作副本吗？

谢谢您的帮助!

我最近在Subversion中发现了一个非常奇怪的合并冲突.我正在使用陆龟SVN作为客户端.请查看以下有关主干和分行详情的信息:

• \树干\ .两个用户正在研究这个问题.
• \ QA \是从主干合并的分支.
• 为简单起见,在\ trunk\ClassLibrary1.sln中有一个visual studio解决方案
• 目前解决方案中有一个示例项目.\干线\ ClassLibrary1的
• 两个用户都已完全更新,并且没有任何工作副本更改.
• 将发生以下事件序列.

1. 用户1将首先在解决方案中添加一个新项目并提交整个目录.(ClassLibrary11)
2. 用户2将获取更新并在解决方案中添加新项目并提交整个目录结构(ClassLibrary12)
3. 上下文:在上面的补充中,ClassLibrary11是我们的特征X而ClassLibrary12是我们的特征Y.现在特征Y是稳定的,完全独立于特征X并且可以移动到QA分支.
4. 合并过程:我们转到QA分支并将功能Y从主干合并到QA分支.它成功合并,没有任何冲突.
5. 在开发3周后,功能X变得稳定,现在我们尝试将功能X移动到QA分支.但是当我们合并时,它会在ClassLibrary.sln文件中给出合并冲突

意图:我们希望将整个流程自动化作为我们的Devops管道的一部分,其中功能(完全独立)可以从仪表板升级到不同的分支,这将合并与功能相关联的修订.在上面的情况下,特征X和特征Y是完全独立的(功能和代码文件也是如此).唯一的共同点是解决方案文件ClassLibrary.sln文件,其中添加了对这两个项目的引用.

Tortoise SVN应该自动发现修订版只是对2个不同提交的重新排序.所以我只是想知道一种方式(重新设计/预防性提交),以免这种冲突发生.如果他们应该发生那么我需要知道,虽然合并功能Y即ClassLibrary12,这将导致未来的冲突