打破了几天的构建

Question

我最近向同事发送了一封电子邮件，说明我需要在共享的ClearCase视图中进行一些更改，这意味着我们的项目将在一天或两天内处于不可编译的状态。

一个人抱怨这个。我该怎么做才能阻止他的抱怨？

Answer 1

在单独的分支中进行更改，并在完成后负责合并您的更改。

我当然可以理解为什么你的同事可能会抱怨这一点 - 你实际上是在阻止他/她做他们本来打算做的工作。

Answer 2

你可以通过不破坏构建来阻止他的抱怨！

构建不仅仅是某个夜间进程发生在某个人无处可关的角落 - 每当他们想要调试或测试任何东西时，它都会发生在每个开发者机器上！

如果构建机器上的构建被破坏，那么它在每台开发者机器上都会被破坏 - 对于开发人员而言，构建应该是 sacred ，因为破坏的构建意味着其他人无法执行他们的工作的

就你可以做些什么来阻止你的更改破坏构建而言，它取决于你正在改变什么，但是一些通用的建议是：

• 在单独的分支上进行更改，并在完成后将其合并
• 避免进行大的更改，而是将您的更改拆分为许多较小的非破坏提交。

Answer 3

<强>要么

• 向他解释为什么你必须这样做，他会理解是否有更好的解决方案

或

• 做更好的解决方案

---

修改

我不知道为什么我会为此投票。基本上，我说你不应该试图“阻止他抱怨”。要么他不理解为什么你所做的是最好的解决方案，或者你所做的不是最好的解决方案。只需走过去和那个人聊聊并讨论问题，直到你们彼此达成一致为止。

你们其中一个是对的，其中一个人错了，我不是说哪个，我没有足够的信息。

Answer 4

如果你正在使用SVN，这应该是一个简单的分支。否则，您可能需要考虑复制/过去操作并在最后合并。

就我个人而言，我认为告诉别人他们工作的东西将在几天内处于不可编辑的状态，这有点令人发指。你基本上是在告诉你的同事两件事。

1. 您的更改更为重要 比他们的
2. 你将无法工作 几天。

Answer 5

处理这种情况的ClearCase方法（例如，在进行长而复杂的合并时可能会发生）是：

• 首先添加标签以在任何更改之前识别情况
• 开始修改

• 如果进程耗时太长而其他用户受到影响（因为他们的动态视图立即反映*新版本，或者因为他们需要更新他们的快照视图，或者因为您使用相同的视图，这是可能的动态视图），然后：

  • 至少停止共享相同的视图，并创建自己的：如果这是快照视图，则可以使用相同的配置规范。在再次编译之前不要签到
  • 理想情况下，使用您自己的分支创建它，从标签开始：这样您可以进行中间签入，然后在最后将其合并。

使用您自己的分支的配置规范，从您在进行任何危险更改之前放置的标签开始，如下所示：

    element * .../MyBranch LATEST
    element * MY_LABEL -mkbranch myBranch
    element /main/LATEST