Excluding Files from Source Control (TeamForge)

[DeeMay]

I’ve started a project which requires using RoboHelp 2019 Classic to update some files. (We haven’t upgraded to RoboHelp 2020 and probably won’t for a while longer.) There have been some source control errors due to files that are in source control that should not be. (We use TeamForge.)

So far I’ve found in particular that $rhvariable$.htm and <file_name>.ldb should not be in source control:

https://community.adobe.com/t5/robohelp/rhvariable-htm-and-lt-file-name-gt-ldb-file-in-robohelp/m-p/...

Then the following file types are also listed as those that should not be in source control:

* projectname.cpd
* projectname.pss
* projectname.hhp
* projectname.trl
* ehlpdhtm.js

https://www.grainge.org/pages/snippets/snippets.htm#sourcecontrol

Am I missing anything? Any other files relevant for a RoboHelp 2019 Classic project that shouldn’t be in source control?

[Amebr]

That's the bulk. Most of those files aren't added if you use the built in source control functions in RH, but I assume you're managing the check-in/out using TeamForge. In which case, you might also avoid other htm files starting with $, as those are related to previewing topics. Mostly they should be cleaned up automatically when the preview is closed, but sometimes they aren't.

I'm not sure if you've decided to source control your output, but if you've decided not to, then also don't add the !SSL! folder, which contains generated output. (I personally don't advise source controlling output, but some companies are adamant 🙂 )

[DeeMay]

Thanks for the reply! Yes, I'm using TeamForge to check-in/out.

I read some of the Adobe information about the RH source control features. It seems to be emphasized as a safeguard when there are multiple authors on a team.  If there are other advantages you've noticed, I'd be interested to hear about them.

[Jeff_Coatsworth]

Why would you go through the hassle of source control if you didn't have multiple authors??

[DeeMay]

Hi Jeff,

Mainly I'm interested in finding out about the possible benefits of RH source control. The help files that are stored in TeamForge are more accessible to our division in TeamForge than having to ask someone else in our large organization to retrieve them from the server for publishing if the tech writer isn't available and something urgent comes up. We're also having to negotiate what substantial changes in our systems that could be temporary depending on how the pandemic unfolds, and there may be a need to revert back to an earlier state quickly. There have been times in the past where there have been multiple authors and there may be multiple authors again as well.

[Amebr]

I'm actually a fan of source control, even for a single writer, assuming the organisation you're in already has a source control system - trying to support source control by yourself as a writer is Not Fun(tm) and I do not recommend.

• You can't easily forget to back up your work.
• If you screw up a find and replace, it's easy to get the last version of one or more files, depending on how badly you screwed up
• If you need to, you can go back to a complete older version to work on, which you may or may not have archived in a manual process.
• It's harder for the organisation to lose the help when it's with the rest of their source files. The amount of orphaned content on file shares is extraordinary. 🙂

That's my two cents. 

[Jeff_Coatsworth]

Well, there you go - multiple authors (potentially) & backup. I've always been a lone author with a good backup regime, so I fall into the source control No Fun™ crowd. Even with the one project that had 2 of us, we worked on opposite sides of the planet, so just zipping it up & sticking it in a shared folder worked fine - I think Peter has referred to this method of handing off as the "hot potato" model.😁