Svn Talend项目上的分支和合并

我们使用Talend Enterprise，并将其连接到我们的SVN服务器。 这使我们能够创建新的分支来启动新的开发人员/错误修复程序

我仍然没有找到一种方法将dev从一个分支巧妙地合并到另一个分支/主干

我所知道的帮助我合并的唯一工具是：

一次将一个作业从一个分支复制到另一个分支的能力

有一个作业比较功能

我觉得最令人沮丧的是：

我必须记住我们一直在更换的工作，因为无法检查两个分支机构的差异（除了手工逐个检查工作）

我必须手动将每个作业从一个分支复制到目标

工作比较慢，所以不适合时不时地做 我认为没有合并工具，一个接一个地复制作业是令人沮丧和容易出错的

---

我遗漏了什么吗？

没有，这几乎涵盖了一切

您必须记住的是，虽然从技术上讲，Talend存储库在后台使用SVN，但与普通SVN存储库相比，它的工作方式有很大不同。在某种程度上，您可以使用Tortoise SVN（其他SVN客户端可用）来进行合并等操作，但需要预先警告的是，与Talend的讨论可能会导致您的支持合同失效，如果您将其搞砸并破坏您的项目

就我个人而言，我倾向于将主干作为主要的开发工作区，并在那里进行所有的开发。通常情况下，我的团队将在单独的项目上工作，因此不会有重叠，但当我们在同一个空间工作时，我们仍然会将自己限制在项目中的固定工作上。这意味着我们不倾向于从主开发主干中获取任何单独的分支

然后，对于释放，我们获取主干的一个标记，它是一个只读分支。这为我们提供了一个稳定的测试基础，然后发布到生产中

如果在一个版本中发现了任何bug，而主干中的开发已经走得太远，无法纠正它并将其作为一个新标记部署，那么我们可以获取标记的一个分支，并在那里进行任何必要的更改，从这个固定分支中释放一个固定标记。然后，我们会将必要的补丁装回主干

---

这代表了如何实现这一点的总体计划，但实际上，我们尝试将更改保持在较小的范围内，并以敏捷的方式进行发布，因此主干不应该（理想情况下）离测试和生产环境太远。我们唯一真正担心整个合并过程的时候，是当我们对项目的体系结构进行根本性的更改，并对其中的大部分进行大规模重构时。这显然是千载难逢的变化。

我同意SVN的使用被视为Talend的内部功能，我使用Tortoise SVN只是为了调试提交过程中的一些问题。可能我只是重新设计了我们数据仓库的一半，以响应用户在我们产品中的实现方式的变化，如此巨大的变化以及许多工作的变化。我希望能够更好地控制在一个版本和当前开发之间发生的更改，以便能够合并，即使是手动合并，也能够确定必须合并的内容，而不仅仅是试图记住它。不幸的是，正如我所说，在Talend中，没有什么比合并更好的了。我倾向于尽量避免将任何东西合并回主干中，因为无论如何（以我的经验来看）SVN都不适合这样做，而Talend对SVN的看法非常糟糕。