Using MKS and RoboHelp

[staciecm]

Has anyone set up MKS to work with RoboHelp? How does it work with compiling, checking in and out, etc?

Thanks!

Stacie

[maniac9999]

Stacy,

I haven't used this product, but I did try to use Documentum with RoboHelp HTML and it didn't work, mainly because RoboHelp is NOT UNC compliant, so I couldn't store RoboHelp content in a separate repository and check in/check out topics. It reallly put a damper on integrating help projects into any content management strategy here at my company.

If MKS wants/needs to "own" and manage the content of your RoboHelp project using a repository (saw the repository mentioned on the website), you're probably out of luck.

We used to use RoboSource Control for check-in/check-out for a single project, and it worked, but it got to be cumbersome, since we were using it for a JavaHelp project and it would lock some of the output files (.jar) to a specific username.

Jim

[MergeThis]

There's a reason that apps like MKS, RoboSource, and SourceSafe are called source control products. They're used to control source files!

As to "lock[ing] some of the output files (.jar) to a specific username," you should never follow RH's default placement of output file folders into the !SSL! directory under the project. Generate your output somewhere far, far away from the project! In addition, you should not add these files to source control: CPD, HHP, LDB, and PSS (they're user- and machine-specific files and can get corrupted if multiple users are accessing the project).

I know that IT and Release Engineering folks just love putting all the output into source control, where they can grab them and add them to their builds. Resist their ideas with all your might! Keep reminding them of what I said in my opening paragraph.

I used MS Visual SourceSafe with a huge project and two authors, with no problems. As far as I know, SourceSafe is the one that plays best with RH. ClearCase and Perforce don't do as well. I have no knowledge about the other two you mentioned.


Good luck,
Leon

[RoboWizard]

In addition to Leon's excellent advice, here is another funny personal anecdote.

I once did a stint for about a year and a half where I was a lone Technical Writer for a small software company. They had about 10 developers. Now I knew I could very easily recover by simply decompiling one of my hundreds of .CHM files and be back in business. However, the developers weren't convinced. They forced the issue and wanted the .CHM output file checked into the source control server at the end of each day. What they failed to realize was that each day I did this, a new copy of the file was inserted. Soooo, after about 30 days, they came crying to me because my .CHMs were using too much disk space in their source control system! Ohhh boo hoo. Needless to say, once this happened I no longer was forced to store output in the source control system.

Cheers... Rick

[staciecm · Accepted solution]

I wanted to post our "solution" to this issue.

We are going to use MKS for all of the files. For small changes, like spelling and grammar, the developers will check out and check in files from MKS. For larger changes, like ToC issues, all pages will need to be checked out. We'll generate WebHelp files once a week by checking out all web help files, then checking them back in.

Whew! I know that it sounds like alot, but this should do the trick for us.

Thanks!

stacie