Hope you might be able to advise.
My colleague and I use RoboHelp 2015 and have 45 projects, version controlled using SVN. We have a working copy on our local machines and we check in and out to the repository regularly, which is on a server elsewhere in the organisation. We have multiple build tags in all projects, some projects alot larger than others.
We noticed a few issues with missing tags over the last few days as we were doing a build for our next release. However, we realised this morning that tags are actually being deleted from multiple projects. We had initially hoped it might have been limited to one project but looks like its more widespread than that.
We are currently trying to find out the extent of the problem. Its a very serious one for us as trying to recreate the tags and retag the correct material appropriately would be one hell of a challenge if even fully doable.
First off, has anyone experienced this before - tags being deleted randomly from projects? Any ideas or leads?
We are going to do trawl through our projects and make sure that only the appropriate RH files are under source control... we have a few instances where, for example, the .pss is under source control. Would that be the cause of the issue?
Also, can anyone confirm if the ehlpdhtm.js file should NOT be under source control? We know it is used for dynamic HTML effects etc but is it recreated each time we open a project?
Huge thanks in advance for any leads.
This is not something that I recall having seen posted on the forums and I do see all posts. That does not mean I can remember them all but this is not coming to mind as a known issue.
I don't use source control but there is something on my site with information given by those who do. The list of files not to save in source control includes the PSS file and the ehlpdhtm.js file!
This is only a guess but I suspect that when you have taken fresh copies from source control, you have trashed the local copies which were the ones needed. With everyone doing that, what's in source control has become just whatever the last person uploaded. Does that make sense?
I don't think your topics will have lost their reference to the tags, it's "just" that they no longer exist. Recreating the tags character perfect should fix things.
I hope this is of some help.
See www.grainge.org for free RoboHelp and Authoring information.
Thanks for coming back to me. It's much appreciated.
'Recreating the tags character perfect should fix things' - could you explain this please? I don't understand.
Aside from having some RH files under version control that shouldn't be version controlled, we are now leaning towards thinking the root cause might be a .cpd related issue.
In a project with missing tags, I deleted the .cpd on my machine and viola, a whole bunch of tags appeared.Thinking that, despite being version controlled, there is a lag between our working copies and the master copy in the repository due to ineffective .cpd files. Is there any logic to what we're thinking?
Going forward, thinking that we'll delete/rename the .cpd on our local copy before each time open a project.
Addled and befuddled.
It's possible the CPD is behind the problem and if that fixes it, it's the easiest way to go.
By recreating, what I meant was say the whole package of tags has names such as one, two, three, four, five and six where you have one and two on your machine, another author has three and four and another has five and six. In that scenario if you add three, four, five and six to yours and the others add what they are missing it should all work again.
By character perfect I meant One_tag is not the same as one-Tag.
As long as you get the tag names spot on, it should work again as the topics with any of those tags should not have been affected.
I trust the CPD is not in source control as that is another of the files that should not be. Trashing it each time is the way I work but, as above, I don't use source control anyway.
See www.grainge.org for free RoboHelp and Authoring information.
I think I understand what you're saying. Thanks for explaining.
On the ehlpdhtm.js file, I know its used in DHTML effects, drop-downs etc.
To confirm... it definitely should NOT be in source control?
Do you know more about this file? Its not created each time like the .cpd? Is it a file that's just used locally when you open a project and doesn't get updated?
Many thanks again,
Some further information on the cpd file.
It's basically an access database that caches information about the project and some local path information. In my experience at a previous job, this can cause problems when one person works on a project that someone else has worked on. For example, John worked on a project. Then Sally worked on the project and added a couple of files and deleted a couple of others. John opens the project, but his cpd doesn't know about the new files, so doesn't show them in the Project Manager. It also doesn't know about the deleted files, so they appear in the project still. On check in, the files get re-added/deleted based on John's version. When Sally opens the project again her cpd still knows about the new and deleted files, so the new files show as missing, and the deleted files are showing up again. Sally is very confused and sure she's going mad. (This is from memory, so the sequence and consequences are a little rough, but you get the idea.)
If you work on individual projects 90% of the time, then you should be fairly safe to keep the cpd file. (This is important when a project can takes over an hour to rebuild the cpd, although thankfully most only take at most a few minutes.) However, before you open a project that someone else has worked on since your last edit, you should delete the cpd so that the cache is built fresh. If you regularly all work on the same projects, you should definitely delete the cpd each time.
My recommended workflow was: 1. Delete .cpd. 2. Manually Get Latest from source control. 3. Open the project. This ensured we had the very latest from source control and the cache was based on the newest files.
Many thanks for taking to time to reply.
Funny but your recommended workflow is exactly the conclusion we came to at the end of the day yesterday.
The behaviour we identified yesterday was that when one of us opened a project (and did NOT delete the CPD file), a tag or build expression would be deleted from the project. We could see the tag/expression removed from the rhbuildtag.apj file via the 'Diff with previous version ' function in SVN. These were tags which would have been added to the projects over the last two/three years, not necessarily newish ones that one of us would have added recently. No other content was affected, just tags and build expressions.
So deleting the CPD each time was our workaround as of yesterday.
I've been using RH for years and interesting how the CPD file still seems to cause issues for users. You've got work to do on that Adobe.
But my colleague found a post that mentioned this very helpful setting: Clear Project Cache (.cpd File) Before Opening Any Project
Pg 26 of the RH 2015 User Guide - https://help.adobe.com/en_US/robohelp/2015/robohtml/robohelp_help.pdf
(Select File > Options. Click General and set the following options to configure options for
using the program and working with project files.
Clear Project Cache (.cpd File) Before Opening Any Project
Controls whether the old <ProjectName>.cpd file will be deleted each time while opening a
project and a new <ProjectName>.cpd will be created from the project files.)
We're now using this setting going forward as it takes the manual deletion/renaming of the CPD file out of the equation.
Thanks for all your help everyone.
RH 2019 New does away with the cpd file, so it'll be interesting to see how this works going forward. I'll be re-assessing whether 2019 New is acceptable for production in about 6 months.
RH 2019 New does away with the cpd file - that is good news. Hopefully, that should that save users everywhere a world of pain.
Please keep us posted as to how you find 2019 in production. Upgrading isn't on our roadmap for this year but if feedback is good, then I think we might have good cause to push for it at our year end.
Many thanks for all the info Peter.