Background: Nearly two years ago (was using RH 7 at the time) we put our main help project under Mercurial source control--with somewhat less-than-desireable results. The way we have Mercurial setup, we basically have a development branch and a release branch. After our developers code something and it passes various tests, reviews, and is documented, it gets moved over (or transplanted) into the release branch and then pushed onto the server for anyone in our company to pull down into their local Mercurial repository. We only have myself and another writer who currently make changes inside the help project, and we communicate with each other so we're not working on the same topic at the same time. Whenever we release a version, I “update” my folder structure to the release branch. This pulls in all the changes that have made on the release branch, including our RH topic edits into my current help project. Then I can build the help with just the content on the release branch.
Problem: But something broke down along the way. I'm now using RH 9. I don't think the issue I'm seeing is a RH problem exactly, but it seems the way RH handles files and folders may have an affect on what's happening. Here's what's happening:
Whenever I update my help content to either the release branch or back to the development branch, I repeatedly have to re-import some .htm files back into the project. For example, I have a folder in my project named 13_hardware_topics. I always--or nearly always--have to re-import the .htms in that folder. Somehow they’re getting removed at least from whatever mechanism RH uses to determine files in a project. The .htm files still exist in the directory and haven't been manually deleted. RH just doesn't always recognize them. The folder, however, still exists inside of RH. Once they’re imported and I continue working on that branch, things are fine. At least things are fine until I have to switch back to a different branch, and then I have to re-import many of these same files again.
Also, we don’t track our CPD file in Mercurial, so we do end up with the problem of the CPD file from our development branch staying inside our release branch or vice versa when we do the branch switch. This isn’t too big of a problem as long as I remember to delete my CPD file before opening the project.
What file tells RH that a topic is part of a project? The .hhp file? Or is it the the .fpj file? Or something entirely different? Or does it get this info from more than one source? If so, what does it look at first?
My guess is that is what is screwed up (or gets screwed up on a branch change). I feel like shouting something like, "Massive hull damage Captain! Structural damage at 35% and climbing!" That's what the innards of this help project feels like.
Project folders and topics are set in the .fpj files. You can remove the hhp file and the project will still work. Remove a topic from the fpj file and it'll be no longer a part of your proejct. Are the modified .fpj files in the directory that has the problem correct?
For your CPD pains, set the option "Clear project cache (.cpd) before opening any project" in Tools > Options. this will force RoboHelp to always rebuild the CPD every time you open a project. This might save you a lot of frustration.
We're having the same problem (using RoboSource, but that's probably not important). What I think is happening is a corruption of the .fpj file. Basically, it "forgets" your topics exist and no matter how often you re-add them, it still won't update. The best solution I've found is to simply open the .fpj file in notepad and add the file names manually. It's not very hard if you have a basic idea about XML. In your case, if I understood your setup correctly, you would need to go into the folder 13_hardware_topics and open the 13_hardware_topics.fpj file. If you don't see the problem topics listed in there... you've found your problem. If you have more questions, feel free to ask.
I don't know how to make this go away completely, but, at least until now, topics haven't dissapeared after I added them manually.
Thanks Willam and thanks Ioana_S. We ended up overwriting our release branch documentation with our development documentation thereby unifying the documentation between branches. Not the best solution but there were other problems going on (not necessarily RH related) that needed to be addressed too that would only be solved by a unification of the documentation. If I run into this problem in the future, I'll be sure to pay attention more closely to what's happening with the fjp files.
Europe, Middle East and Africa