2014-10-29 66 views
0

我们使用Talend Enterprise,并将它连接到我们的SVN服务器。 这使我们能够创建新分支来启动新的开发人员/错误修正。在Talend项目上分支和合并

我还没有找到一种巧妙地将分支机构的开发人员合并到另一个分支机构/主干的方法。

我知道的帮我合并的唯一工具是:

  1. 一个工作在同一时间从一个分支复制到另一个
  2. 有一份工作比较功能
的能力

我觉得最令人沮丧的是:

  1. 我必须记住我们一直在改变的工作,因为有n o检查两个分支之间的差异(除了用手逐个检查工作);
  2. 我必须手动将每个作业从一个分支复制到目的地;
  3. 工作比较比较慢,所以现在不适用了;

我认为,没有一个合并工具,并诉诸易复制的工作一个接一个令人沮丧和错误

我缺少的东西?

回答

1

不,几乎涵盖了一切。

你必须记住的是,虽然技术上在后台使用SVN,但与普通的SVN存储库相比,Talend存储库与它的工作方式有很大的不同。在某种程度上,你可能会逃避使用Tortoise SVN(其他SVN客户端可用)来完成你的合并等,但是必须预先警告,从与Talend的讨论中可能会使你的支持合同失效,如果你搞砸了并且破坏了你的项目。

对我个人而言,我倾向于将树干作为主要开发工作空间,并在那里进行所有开发。通常我的团队将在单独的项目上工作,因此不存在重叠,但是当我们在同一个空间工作时,我们仍然会限制自己在项目中设置作业。这意味着我们不倾向于从主发展主干采取任何单独的分支机构。

然后释放我们采取一个只读分支树干的标记。这为我们提供了稳定的测试基础,然后再发布到生产环境。

如果在发布中发现任何错误,并且主干中的开发移动得太远而无法更正并将其作为新标签进行部署,那么我们可以采用标签的一个分支并在那里进行必要的更改,释放一个固定的来自这个固定分支的标记。然后我们会将必要的修补程序移植到主干上。

这代表了这种需求如何发生的总体计划,但实际上我们尝试并保持对事物的小改变并以敏捷的方式发货,因此干线不应该(理想情况下)远离测试和生产环境。我们唯一一次真正担心整个合并过程的时候,是我们对一个项目的架构进行了根本性的改变,并且正在大量地重构它的大块。这显然应该是一次蓝月亮式的变化。

+0

我同意SVN的使用被认为是Talend的内部,我只使用Tortoise SVN来调试提交中的一些问题。 也许我只需要重新设计一半的Data WareHouse来响应用户在我们的产品中的实现方式的变化,因此BIG变更和许多作业都在一起。 希望能够更好地控制一个版本和当前开发之间的变化,以便能够合并(甚至是通过手工),确切知道需要合并的内容,而不仅仅是试图记住它。 – RobMcZag 2014-10-30 16:57:34

+0

不幸的是,正如我所说的,在Talend中并没有更好的合并。我倾向于试图避免任何需要将任何东西重新合并到主干中,因为无论如何SVN并不是那么好(根据我的经验),而Talend对SVN的承担可怕。 – ydaetskcoR 2014-10-30 17:07:39

+0

抱歉,完全同意。愿意错了。 :( – RobMcZag 2014-10-30 17:15:52