如何更有效地使用MKS Integrity（源代码管理）

Question

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

什么是我应该知道并避免的一些“陷阱”？而且，有没有关于软件的任何细节能够让我更好地使用它？

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

Answer 1

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

碰到这样说： 有人对我们的球队改名为一个PDF资源，增加_old的文件名（他这样做，而不是放弃它，因为他希望它仍然是我们部署的一部分）

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

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

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

由于MKS只适用一个标签，一个修订版，当我去查看检查点，它看上去就像是不包括在我们部署新的PDF，因为它缺少标签

此外，避免视觉STUDIO INTEGRATION !!!自从安装它以来，我的团队中有几个成员不得不经常与视觉工作室崩溃搏斗，显然其分支机制依赖于完整性命令行或gui客户端中没有等效功能。因此，如果您团队中的任何人使用Visual Studio集成，除非他们工作的分支是通过集成创建的，否则他们将无法工作。所以你会发现自己在Visual Studio中做了一些事情，Visual Studio的工作很慢而且很差，所以使用集成的团队成员可以使用它。

Answer 2

自1999年以来，我一直使用源代码管理。它非常可靠，我们从未丢失过更改历史记录。我们不会对分支做任何事情，所以我不能回答你的问题。

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

SI基于命令行设计。如果您使用命令行版本（pj.exe等），则可能会得到更一致的结果。文档不是微不足道的。

我们正在尝试迁移到Subversion，因为MKS想要他们最新的企业版本的荒谬资金。