Storing WebHelp output in Perforce

[7man40]

I use Perforce to control Flare v6 source files and it works fine. But I also store an entire Flare Webhelp system in Perforce so it is available during the build of the large application it is part of. This works fine most of the time but we get occasional problems with the Webhelp when it is invoked from the completed application (bad PR for tech pubs!). It tends to fix itself if I run another Webhelp build and check it in again. I suspect there is some problem with the interaction of Perforce with the Webhelp files. The problems that happen are always the browser complaining about a scripting error, and it references one of Flare's Webhelp JavaScript files. I can get more specific but I mainly wanted to ask if you think this is wise, to put an entire large (1700+ files) Webhelp system in Perforce. I am thinking that there might be some weird text file encoding incompatibility or something (this happened a couple of times with the Flare source files).

Do you think it would be wiser to have our the engineering build pull in the Webhelp system from a file system, outside of Perforce?

Thanks,
Mark

[RamonS]

You can use Flare's command line build to build the help as part of the build process. Storing the output from Flare in source control is not the way to go, after all it is called source control. Assuming that Perforce doesn't monkey around with the Flare project files keeping those in Perforce and building help output when needed is a better approach. I intentionally call it a "better approach" rather then the best or only way, because there are a few reasons why storing output in source control may make sense. Typically, it is done because the build process of the entire application installer is easier that way, but then the same could be said about the program code as well.
So, is there a particular reason why you keep the output in source control?

[7man40]

Thanks for reminding me about Flare command-line help builds. I'm going to look into it. As for why I am putting Webhelp output in Perforce, I inherited the practice from someone at my client a few years ago. I'm not sure why he did it, but I will assume it was because it was a formal way to supply the help system to engineering, and it provided more control than simply dropping the help on some network drive. And Perforce is the centerpoint of the builds.

But checking in 1700 generated Webhelp files seems kind of ill-advised to me (and it takes a long time). And frankly it seems a little goofy, now that I really think about it. I'm going to look for another way to handle this. I may or may not be able to talk the engineering department into building Flare as part of their software build. And I assume it would require another Flare license for the build server.

If the help build is not incorporated into the application build system, what is a usual way for a tech pubs department to pass off a help system to engineering? Putting the Webhlep files on a network drive?

Thanks for facilitating a rethink of this process.

Mark

[RamonS]

As far as the licensing goes, you need a license per concurrent user. That means if builds run at night and you don't work at 3 in the morning then it should be fine to use the same license. The only problem is that you'd need to close your copy of Flare. Many times before I recommended to MadCap to provide licenses that allow Flare nothing else than running the command line build. That would allow for including it in automated build processes without buying a full license for using only one feature of Flare. Call sales or support and ask them about it. Maybe they have a solution for this.

[7man40]

I appreciate the advice on licensing. What is your opinion on this:

If the help build is not incorporated into the application build system, what is a usual way for a tech pubs department to pass off a help system to engineering? Putting the Webhlep files on a network drive?

Thanks,
Mark

[RamonS]

I'd have it on a network share and keep only the help sources in source control. Whatever is on the network is what is considered 'latest'. That also has the advantage that you can check in sources that are still a work in progress without QA wondering why you covered only half of a feature.

[7man40]

Thanks, I appreciate your help. I have a lot of useful ideas now.