如何更有效地使用MKS Integrity（源代码控制）

Question

我们使用MKS Integrity作为源代码控制。我无法控制 - 我只需要使用它。

我应该知道并避免哪些“陷阱”？而且，软件是否有任何巧妙的东西可以让我更好地使用它？

我已经遇到过源控件中的树结构与我的沙箱中的树结构不匹配的情况。在不止一种情况下，文件存在于两个地方，当我重新同步时，我得到当前版本，然后旧版本覆盖它，然后它不再同步。找到旧文件是一个挑战，因为当然，树结构不匹配。

Answer 1

我从1999年开始使用Source Control。它非常可靠，我们从未失去过变更历史。我们不会对分支做任何事情，所以我无法回答你的问题。

我假设你重新同步（F6）并更新到head（F7）。

SI基于命令行设计。如果使用命令行版本（pj.exe等），则可能会获得更一致的结果。文档并非易事。

我们正在尝试迁移到Subversion，因为MKS希望他们最新的企业版本可笑。

Answer 2

刚刚发现这个MKS问题：它只允许一个成员的一个修订版一次有一个特定的标签。

以这种方式遇到它： 我们团队中的某个人重命名了一个pdf资源，将_Old添加到文件名中（他这样做而不是放弃它，因为他希望它仍然是我们部署的一部分）

然后他添加了新版本的pdf，将其添加到同一档案中，以便连接到现有的修订历史图表。

现在，如果您查看该成员的修订历史记录，您会发现同一个dev路径正在使用同一成员的两个修订版。

作为部署过程的一部分，我们检查正在部署的工件，将标签应用于成员以指定他们所属的版本。

由于MKS仅将标签应用于一个修订版，因此当我查看检查点时，我们的部署中似乎没有包含新的pdf，因为它缺少标签

此外，避免可视化工作室集成 !!!自安装以来，我的团队的几个成员不得不与频繁的视觉工作室崩溃进行斗争，显然其分支机制依赖于在完整性命令行或gui客户端中没有等效的功能。因此，如果团队中的任何人使用visual studio集成，除非他们所在的分支是通过集成创建的，否则它们将无法工作。因此，你会发现自己陷入视觉工作室的困境，因为视觉工作室的工作进展缓慢而且很差，以便使用集成的团队成员可以使用它。