3

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.

Kara
  • 6,115
  • 16
  • 50
  • 57
thursdaysgeek
  • 7,696
  • 20
  • 78
  • 115
  • I'm currently stuck using MKS, and not doing it very well. Did you manage to get some hints on this? – Marty Pitt Jan 24 '11 at 20:32
  • No. You can see the interest this question has generated. I continue to muddle along. The general concensus at work is that it is fine for documents, not so good for source code that is being worked on, especially not when there is more than one programmer working on the same project. I have my sandbox away from the actual code, and copy it from a working location to the sandbox to MKS. It's awkward, but I've also never lost any working code. – thursdaysgeek Jan 24 '11 at 23:46
  • I'm wrestling with MKS myself. Have you learned anything since? Right now I'm trying to figure out how to create the "Shares" that their Visual Studio Integration uses from the command line – Michael Lang Apr 18 '11 at 17:10

2 Answers2

1

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.

0

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.

Michael Lang
  • 2,157
  • 3
  • 22
  • 29