Robohelp 2015 generate output to TFS

[adoP33]

My webhelp output gets generated to my local C:\ instead of to Team Foundation Server. This means that the !SSL! subdirectory only exists on my local machine and never gets placed into TFS.

I have provided screenshots of my TFS project directory and its contents vs. my local directory (where output files get generated to).TFS project directoryAdditional content inside TFS project dir

[Amebr · Accepted solution]

Typically developers get very upset if you put output files into the source control system. 

Can I ask why you want to add the output? 

If you're determined, you'll need to add the output folder (the !SSL! folder if I'm interpreting your last image correctly) manually using TFS itself. And you'll need to remember to manually check it out using TFS before you generate, and then check it in after you finish generating.

[adoP33]

@Amebr

So, to answer your question, as to "why I want to add the output": because I do not know what files TO put in the source control system, I put all files in the source system.  

My other post made in February concerned runtime files (which from the Robohelp 2015 manual: https://help.adobe.com/en_US/robohelp/2015/robohtml/robohelp_help.pdf) on p. 498, seem to inform me of a path forward, but I need additional detail on distribution of WebHelp to know the Best Practice.

--Background--

I am using Robohelp 2015 that I integrated with TFS (FYI). As the developer, I use the Microsoft stack of MSSQL, IIS, C# with ASP.NET framework Webforms, I wish to care as little about Robohelp as I need to. 

I believe I may not be the only one in the Robohelp community that is tasked with creating some help files when development is my main job. 

[Jeff_Coatsworth]

Usually RH projects are checked into source control systems only when there are multiple authors working on them. If you're on your own with maintaining a help system, I wouldn't bother with it. Since you're the developer, you know what output you want to produce and where it should go to be used in your program. Maybe you should just set up RH to publish to that location directly?

[adoP33]

Hi, Jeff.

That is a great thought.

Budget though be as it may prevents us from warranting such action and deviation from current state.

Additionally, we have multiple authors/hands, since the OG Robohelp author left. I am the new one and departing shortly and will pass it to a system administrator & a lead developer to manage after I leave in a weeks time.

After discussing with my manager, I have a comment for feedback.

Comment: If it is true that output file generation (!SSL! subdirectory which contains the WebHelp output files) can be generated using all other project files that are maintained on TFS, then RoboHelp's Batch Generate option inside the Output tab will satisfy creating the WebHelp folder and its contents to a location we as developer's can designate. (Please validate truth value).

[adoP33]

Jeff_Coatsworth: I thought you were suggesting purchasing Robohelp Server. Nonetheless, any Robohelp developer will be a guy/lady coming in picking up the project where somenone left off, and TFS needs to store Joe Schmoe's work so that when he leaves his progress can be picked up by another.

[Jeff_Coatsworth]

Who mentioned anything about RH Server??
Generally users of RH are tech writers/authors. If there is only one author using it, it usually is cheapest to install RH on a workstation and work on the project files locally, employing regular backups of the project files for safety.
When there are multiple authors involved, some sort of sharing process must be employed because no one topic can be worked on by multiple people at the same time. Topics are checked out of source control to lock them in the source control system to prevent others working on them at the same time. This is NOT like programming pull requests and commits because RH files are not text files that can deal with merges.
In either case, when it's time to produce output, an author must check out the project, and generate the output (locally to that \!SSL!\output_type\ folder). The output is them manually copied to wherever it is needed for deployment and distribution - in my world, I create a self-extracting executable because my help is installed on our clients' LAN servers and not a webserver. 
There also exists a "Publish" option that creates the output and transfers it to whatever location is desired (it's like FTPing it up to some webserver out there; sometimes it's to a Sharepoint instance or other developer-controlled location for inclusion in their build process).

[Amebr]

I'll respectfully disagree with Jeff and say that source control can be great for a single author IF you already have a source control system. 🙂 

Now back to your issue.

For the source files, don't include the *.cpd, *.ldb, *.pss file in source control. These contain author specific information and can screw things up when you have multiple authors. Delete them from source control if they're there.

Some people say you shouldn't include the *.hhp file either, but I never found a problem with it, and having a backup saved my bacon on a couple of occasions. YMMV.

For future reference, if you use the RH interface to add a project to source control, it will add only the necessary files to source control.

To add to Jeff's info about copying the output, don't be tempted to leave any files out when you copy, they really are all necessary. However, if you use the Publish function, you can choose to only publish changed files, which will reduce the number of files transferred over the network. I do recommend using Publish, it saves time.

Oh, and don't be tempted to generate to your final destination (either web server or network location). While it might work short term it's a bit like Russian roulette. Publishing to a network location is fine, but definitely generate locally.