version-control - 使用 Rational Team Concert 有哪些风险？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




使用 Rational Team Concert 有哪些风险？在软件开发中？

Answer 1

我知道这是一个旧线程，但如果其他人来过这里，我会分享我的个人经验。

过去几年我们一直在这里使用它，作为顶篷 RTC 已经发展成为 SCM，我根本不信任我的文件。

工作流是如此不同，以至于其他 SCM 的工作流和整个系统都如此不同，它是一个过于复杂和复杂的系统，有时会导致您丢失更改。

事实上，有一篇关于一个名为“Backup Shed”的假设功能的文章只是说明我没有错，需要这样一个功能的事实本身就说明了一个关于变化如何突然消失的故事.
- https://jazz.net/library/article/191/?errno=1

从其他 SCM 来看，我们几乎习惯于只有“恢复”覆盖本地更改。在 RTC 中，这种情况发生在许多其他场合。有人要问，在这些情况下合并文件和/或冲突它们可能有多难？...

当您执行以下操作时，RTC 将覆盖文件:

重新同步您的工作区，并且由于您无法从不同步的 WS checkin ，因此您无法避免这种情况，所以上帝啊，在这样做之前进行备份!

接受更改，是的，这是正确的，尽管所有其他 SCM 所做的...它会提供您在接受更改之前检查本地更改，因此请记住在 处单击"is"。祈祷 它已经发现了所有局部变化。

随机？...我相当肯定也经历过其他变化消失的情况，但只有上面的 2 个是我能够触及的东西...

还原...显然，实际上应该在此列表中的唯一一个项目符号。

这可能是“设计”造成的……但是我想为非常糟糕的设计投一票。

此外，如果您使用的是 Visual Studio，请始终在 checkin 之前单击刷新远程和本地更改。作为 subversion(旧)的解决方案在发现更改方面比 RTC 好很多，GIT 也是如此...

此外，SVN 和 Git 在许多 IDE 中也有很好的实现......我认为 Git 可以在 Visual Studio 中使用需要一段时间，但现在确实如此!虽然仍然有希望的功能。 SVN 也可以与许多工作项/问题跟踪系统集成，但对于 Jira 集成，我实际上更喜欢在评论中写下问题编号，它更快更容易......它会在 FishEye 拾取时创建链接更改集，因此 Jira 将显示对问题的提交。

我不能说 Git/Stash 组合或 SVN 与 YouTrack/Mingle 在这里是如何工作的。但是在 RTC 中，将工作项附加到提交的工作流变成了巨大的开销，因此我们停止使用它 = 无值(value)的功能。

然后是系统的整个计划、工作项、Scrum 等部分……我唯一喜欢的部分是它不时给我带来的笑声。除此之外，它几乎没用……转而使用 Jira+GreenHopper、Mingle、YouTrack……

一件有趣的事情是，IBM 试图在“集成”上出售它以及您在其中节省了多少......由于这些解决方案分布广泛，因此有大量好的解决方案可供您进行设置和在您决定可能是升级到该软件的较新版本之前，您无需触摸手指。除了所有这些“应该为管理员节省时间”之外，只需让他们四处奔波并帮助解决 RTC 似乎带来的许多问题。

所以我建议反对RTC。 Github、Codeplex、Bitbucket 等已经证明，Git、SVN 等实际上确实可以扩展……