How to use MKS Integrity (source code control) more efficiently [closed]

Question

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.

Answer 1

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.

Answer 2

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.