Copy link to clipboard
Copied
My RoboHelp 2019 project includes a number of .rh cache files and folders.
Are these something I should just ignore?
I was using RH2015 before the upgrade, and the only cache I was aware of was the .cpd file.
It seems that now I every time I edit a file there's a cached version.
We use Subversion for version control, so when committing changes I have to carefully review the entire filellist and choose not to commit those cache files.
Hi Nick,
Files inside .rh folder need not be checked-in to version control.
Topics kept inside top-level-foldername/.rh/.nicks.fr.cache/contents have topic files whose text is saved here for find and replace feature. We find in these files for text search.
Files like .username.db.json is for reading the project while opening. Project open is faster with this cache file.
File .username.preferences.json contains detail related to recently opened files, generated outputs etc.
So yes, recommendat
...Copy link to clipboard
Copied
I can't answer definitively, not having source control myself, but this page on Peter's site "suggests" it's probably okay to leave out of source control. It says you can delete it and it will be rebuilt, which is my only justification for my thought.
http://www.grainge.org/pages/authoring/opening/opening_projects.htm
A way to test might be to add a small test project to subversion using the tools within Robohelp. Theoretically, anything RH doesn't add to source control is fine to leave out. Always assuming the same behaviour from RH8 or so (when last I used VSS) has made it all the way through to RH2019 New.
Copy link to clipboard
Copied
Thanks, for such a swift response, Amebr.
Peter's "suggestion" sounds very encouraging.
RH is doing nothing itself with SVN; no PushOk SVN SCC plugin or anything. I just commit the changes myself "manually" using the ubiquitous TortoiseSVN – right-click in File Explorer and click SVNCommit.
I've been doing that for years, and just continued doing it after upgrading to RH2019. Yesterday I was committing some changes while the project was open (although the topics were saved), which is probably why cached files were in my list of changes to commit.
Copy link to clipboard
Copied
Oh, and if it turns out it is okay to leave out, speak to your developers as there might be a way to specify a whole folder to ignore when checking in/out so you don't have to waste time thinking about it. I've heard people talking about a gitignore file elsewhere on the intertubes, so I imagine most source control tools have a similar ability.
Copy link to clipboard
Copied
Thanks, Amebr. I already know about SVN's "ignore list" feature; I'll have to see whether it whether I can get it to ignore an entire folder and its contents instead of selected files/folders or file patterns.
Copy link to clipboard
Copied
Yep, I gathered you were using SVN outside of Robohelp. In older versions (RH8, from memory) using the VSS integration, when I added a project to source control from within RH, it would exclude the SSL folder, the cpd, ldb and a couple of other files. So I was thinking adding a test project using the integration might show what Robohelp considers necessary, for additional certainty.
Oh and the suggestion that it can be left out of source control is my own, not Peter's. He just says it can be deleted and RH will rebuild it. I don't want to put words in anyone else's mouth. 🙂
Copy link to clipboard
Copied
My RoboHelp 2019 project includes a number of .rh cache files and folders.
Are these something I should just ignore?
As long as you are only talking about the files that have the word "cache" at the end, my understanding is that these are rebuilt when a project is reopened. My take therefore would be there is no point in checking them in and out. Nonetheless I am checking with Adobe.
I was using RH2015 before the upgrade, and the only cache I was aware of was the .cpd file.
Yes but 2019 works in a very different way and the two cannot be compared.
It seems that now I every time I edit a file there's a cached version.
Yes, that's to enable Undo.
****************************************
I am also checking with Adobe about the other .rh files you will see. They include the author's profile name and information for that author. Where is see a danger is when you check out a project, make some changes and then check back in. You check out to work on the project and ten minutes later another author does the same. Then an hour later you check it all back in and ten minutes later so does the other author. Potentially you could overwrite another author's .rh file.
I don't know how things work in that scenario. I am trying to clarify that with Adobe.
Copy link to clipboard
Copied
Many thnks, Peter. Yes, I was talking about files that have the word "cache" in them. For exanmple:
top-level-foldername/.rh/.nicks.fr.cache/contents/foldername/filename.htm
top-level-foldername/.rh/RH_TEMPfoldername
I'll continue not committing them, and see if i can set up an ignore list to ease the reviewing of the list of files changed.
I'm actually the only author, but work on the same projects in two locations on different machines, so SVN enables me to keep those copies in sync, (And since the outputs go into SVN as well, Devops can deploy my builds.) So there should be no risk of multiple checkouts/updates and commits messing things up, but it will be interesting to hear what Adobe says.
Copy link to clipboard
Copied
Hi Nick,
Files inside .rh folder need not be checked-in to version control.
Topics kept inside top-level-foldername/.rh/.nicks.fr.cache/contents have topic files whose text is saved here for find and replace feature. We find in these files for text search.
Files like .username.db.json is for reading the project while opening. Project open is faster with this cache file.
File .username.preferences.json contains detail related to recently opened files, generated outputs etc.
So yes, recommendation is not to check-in these files to version control. We make a ignore list of these files for our out of the box version control sysytems like GIT, TFS etc.
Thanks and Regards,
Surbhi Maheshwari
Copy link to clipboard
Copied
Thank you, Surbhi, that's just what I wanted to hear.
Cheers,
Nick