我们使用 MKS Integrity 进行源代码控制。我无法控制它——我只需要使用它。
我应该知道和避免哪些“陷阱”？而且，该软件是否有任何巧妙的东西可以让我更好地使用它？
我已经遇到了源代码管理中的树结构与我的沙箱中的树结构不匹配的情况。在不止一种情况下，一个文件存在于两个地方，当我重新同步时，我得到了当前版本，然后一个旧版本覆盖了它，然后就不再同步了。找到较旧的文件是一项挑战，因为当然，树结构不匹配。
thursdaysgeek
问问题
9809 次
2 回答
1
我从 1999 年开始使用 Source Control。它非常可靠，我们从未丢失过更改历史记录。我们不会对分支做任何花哨的事情，所以我无法回答您的问题。
我假设您确实重新同步 (F6) 并更新到 head (F7)。
SI 建立在命令行设计之上。如果您使用命令行版本（pj.exe 等），您可能会得到更一致的结果。文档不是微不足道的。
我们正在尝试迁移到 Subversion，因为 MKS 想要为他们最新的企业版本提供可笑的资金。
于 2009-07-23T11:46:21.643 回答
0
刚刚发现了这个 MKS 陷阱：它一次只允许一个成员的一个修订版有一个特定的标签。
遇到这种情况：我们团队中的某个人重命名了一个 pdf 资源，在文件名中添加了 _Old（他这样做而不是删除它，因为他希望它仍然是我们部署的一部分）
然后他添加了新版本的 pdf，将其添加到同一个存档中，以便它连接到现有的修订历史图表。
现在，如果您查看该成员的修订历史记录，您会发现同一成员的两个修订版本被同一开发路径使用。
作为我们部署过程的一部分，我们检查点正在部署的工件，将标签应用于成员以指定他们所属的版本。
由于 MKS 仅将标签应用于一个修订，因此当我查看检查点时，看起来新的 pdf 未包含在我们的部署中，因为它缺少标签
另外，避免视觉工作室集成！自从安装它以来，我团队的几个成员不得不与频繁的 Visual Studio 崩溃作斗争，显然它的分支机制依赖于完整性命令行或 gui 客户端中没有等效的功能。因此，如果您团队中的任何人使用 Visual Studio 集成，除非他们工作的分支是通过集成创建的，否则它们将无法工作。因此，您会发现自己被困在 Visual Studio 中做的事情，Visual Studio 做的很慢而且很差，只是为了让使用集成的团队成员可以使用它。
于 2011-04-18T17:10:07.827 回答