如何更有效地使用 MKS Integrity（源代码控制）
我们使用 MKS Integrity 进行源代码控制。 我无法控制它——我只能使用它。
我应该了解并避免哪些“陷阱”？ 而且，该软件有什么巧妙的地方可以让我更好地使用它吗？
我已经遇到过源代码管理中的树结构与我的沙箱中的树结构不匹配的情况。 在不止一种情况下，一个文件存在于两个地方，当我重新同步时，我得到当前版本，然后旧版本覆盖它，然后它不再同步。 找到旧文件是一个挑战，因为树结构当然不匹配。
We use MKS Integrity for our source control. I have no control over that -- I just have to use it.
What are some "gotchas" that I should know about and avoid? And, are there any neat things about the software that will allow me to use it better?
I've already hit cases where the tree structure in the source control doesn't match that in my sandbox. In more than one case, a file exists in two places, and when I resynchronize, I get the current version, and then an older version overwrites it, and then it is no longer synchronized. It's a challenge to find the older file, since, of course, the tree structure doesn't match.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我从 1999 年开始就使用源代码管理。它非常可靠，我们从未丢失过更改历史记录。 我们不会对分支机构做任何花哨的事情，所以我无法回答你的问题。
我假设您确实重新同步（F6）并更新到磁头（F7）。
SI 是建立在命令行设计之上的。 如果您使用命令行版本（pj.exe 等），您可能会得到更一致的结果。 该文档并不简单。
我们正在尝试迁移到 Subversion，因为 MKS 想要为其最新的企业版本提供可笑的资金。
I have used Source Control since 1999. It's pretty reliable, we have never lost change history. We don't do anything fancy with branches so I can't answer your question.
I assume you did resynchronize (F6) and update to head (F7).
SI is built upon a command-line design. You might have more consistent results if you use the command-line versions (pj.exe etc). The documentation is not trivial.
We're trying to migrate to Subversion, because MKS want ridiculous money for their latest enterprisey version.
刚刚发现了这个 MKS 陷阱：它一次只允许一个成员的一个修订版具有特定的标签。
是这样遇到的：
我们团队中的某人重命名了 pdf 资源，将 _Old 添加到文件名（他这样做而不是删除它，因为他希望它仍然是我们部署的一部分）
然后他添加了 pdf 的新版本，将其添加到同一个文件中存档，以便它连接到现有的修订历史记录图。
现在，如果您查看该成员的修订历史记录，您会发现同一开发路径正在使用同一成员的两个修订版。
作为部署过程的一部分，我们检查正在部署的工件，将标签应用于成员以指定它们所属的版本。
由于 MKS 仅将标签应用于一个修订版，因此当我去查看检查点时，新的 pdf 似乎未包含在我们的部署中，因为它缺少标签
此外，避免 VISUAL STUDIO 集成！ !! 自从安装它以来，我团队的几位成员不得不与频繁的 Visual Studio 崩溃作斗争，显然它的分支机制依赖于完整性命令行或 GUI 客户端中没有等效项的功能。 因此，如果团队中的任何人使用 Visual Studio 集成，除非他们工作的分支是通过集成创建的，否则他们将无法工作。 因此，您会发现自己被困在 Visual Studio 中做一些事情，而 Visual Studio 做得又慢又差，只是为了让使用集成的团队成员可以使用它。
Just discovered this MKS gotcha: It only allows one revision of a member to have a specific label on it at a time.
Came across it this way:
Someone on our team renamed a pdf resource, adding _Old to the file name (he did this rather than dropping it because he wanted it to still be part of our deployments)
Then he added the new version of the pdf, adding it to the same archive so that it connects to the existing revision history graph.
Now, if you look at the revision history for that member, you'll find that there are two revisions of the same member being used by the same dev path.
As part of our deployment process, we checkpoint the artifacts that are being deployed, applying labels to members to specify the release that they're a part of.
Since MKS only applies a label to one revision, when I went to review the checkpoint, it looked like the new pdf was not included in our deployment because it was missing the label
Also, AVOID VISUAL STUDIO INTEGRATION!!! Since installing it, several members of my team have had to wrestle with frequent visual studio crashes, and apparently its branching mechanisms depend on features that have no equivalent within the integrity command line or gui client. So if anyone on your team uses visual studio integration, unless the branches they work in were created through the integration, they will not work. So you'll find yourself stuck doing things in visual studio that visual studio does slowly and poorly just so that the team members using the integration can work with it.