Switching from Web Help to HTML5 in a Linux Enviro

[erinep23]

So, my developers are freaking out because before we had a regular Web Help output that was part of the build and accessed through the application. We use Assembla/SVN to store stuff. Well, I switched the target to HTML5, and now the folders look different from my local and what is stored in SVN. And they seem to think bc it's a Linux shop that it will break - has anyone had this experience? Did it go off without a hitch? (I'm working with a developer that makes things way harder than it is.)

And also, (And I know this is a stupid question) but I do need to bind the project to SVN right? In a scenario where the output is a static entity going out in the application package to customers?

I hope some of this - any of this - is making sense.

[NorthEast]

The output folder structure is actually roughly the same in WebHelp and HTML5 outputs; however, they're quite different outputs and will have different files, so just treat the HTML5 output as being brand new so it entirely replaces the old WebHelp. You don't want to merge the new help in with any of the old files.

Note that in your screenshots you're not in the same folder; the SVN screenshot shows the content/resources folder, but if you move up to the WebHelp folder you should see the same Default.htm files and a similar folder structure.

I noticed that your output folders in SVN appear to use lower case; so if that's important, and you set the WebHelp target to Use lowercase filenames (on the target Advanced tab), then do the same for the HTML5 target.

[erinep23]

Fantastic - thanks for your help!

[hjnb]

And also, (And I know this is a stupid question) but I do need to bind the project to SVN right? In a scenario where the output is a static entity going out in the application package to customers?

Not a stupid question at all. If you need/want to maintain your Flare source files in SVN, you can bind the project to SVN so that updates to SVN happen through Flare OR you can choose to manually do the updates to SVN with applications such as TortoiseSVN. Generally you'll want to choose one of the two methods and not switch between them.

Even if the content is truly static, it can be nice to have your working files in source so you can readily revert to a previous version when, for example, a SME changes their mind on a feedback.