My developers are trying to check in my Flare 9 webHelp-compiled help system into ClearCase.
They are getting errors back from ClearCase on the .js, .XML and .CSS files that Flare generates as part of the compilation into WebHelp and HTML5.
They get back errors for madcapall.js (for example) that it cannot be checked in:
Unable to checkin: help\Content\SkinSupport\MadCapAll.js
text_file_delta: Error is not a 'text file: it contains a line exceeding 8000 bytes. Use a different type manager such as compressed file."
Any ideas?
The problem seems to be that the .js files have a tons of characters without line breaks, and ClearCase prevents that.
Buildmeister suspected that it needs to be checked in as a binary, but Dev hasn't tried it yet.
We can only build either WebHelp or HTML5 help for the particular project, since it's a web app.
Any thoughts!? Any ideas would be greatly appreciated!
Flare Help system and ClearCase
Re: Flare Help system and ClearCase
I use Perforce not Clearcase, but I think some of what I am about to say may be relevant to your case too.
I always zip up my webhelp output before checking into source control, so that the checkin is just one file of a known name, rather than hundreds and hundreds of individual files. Each time the webhelp is generated, even if you don't change any of the filenames of your topics etc, you may find that Flare changes some of the files it creates. In that case, the next time you generate the help and want to update the version in source control, you will have a terrible job working out which files are old and must be deleted, or new and must be recreated. And you will have the same problem if you add, rename or delete files yourself. You'll need to reapply those changes manually again in the generated output area.
So, if you must check in generated webhelp, I'd strongly recommend that you zip it into a single file first. I'd also recommend that you get your developers to write you a script to automate the generation of the zip file from your generated files, because it's easy to create a zip file that starts at a different level in the folder tree from the last time it was created. In that case, when it's unzipped you may find it doesn't look quite like it did the last time, which may confuse the application when it comes to look for it.
However, in an ideal world, you wouldn't need to check in any generated files into source control. In the same way as the executable code is probably built automatically from the checked in code sources, and is probably not checked into source control after being built, your webhelp output would be built automatically from your checked in Flare sources. That's a job for MadBuild.
However, I can't talk, as I still have to check my generated outputs into source control, but I'm hoping that will change soon. This is a hang-over from the days when PDF creation was a manual process from Word files, but it's really not necessary now. But it is worth asking your developers if your webhelp could be auto-built in the same way as their generated executable code. In the longer term, this would make your life (and theirs) far simpler.
I always zip up my webhelp output before checking into source control, so that the checkin is just one file of a known name, rather than hundreds and hundreds of individual files. Each time the webhelp is generated, even if you don't change any of the filenames of your topics etc, you may find that Flare changes some of the files it creates. In that case, the next time you generate the help and want to update the version in source control, you will have a terrible job working out which files are old and must be deleted, or new and must be recreated. And you will have the same problem if you add, rename or delete files yourself. You'll need to reapply those changes manually again in the generated output area.
So, if you must check in generated webhelp, I'd strongly recommend that you zip it into a single file first. I'd also recommend that you get your developers to write you a script to automate the generation of the zip file from your generated files, because it's easy to create a zip file that starts at a different level in the folder tree from the last time it was created. In that case, when it's unzipped you may find it doesn't look quite like it did the last time, which may confuse the application when it comes to look for it.
However, in an ideal world, you wouldn't need to check in any generated files into source control. In the same way as the executable code is probably built automatically from the checked in code sources, and is probably not checked into source control after being built, your webhelp output would be built automatically from your checked in Flare sources. That's a job for MadBuild.
However, I can't talk, as I still have to check my generated outputs into source control, but I'm hoping that will change soon. This is a hang-over from the days when PDF creation was a manual process from Word files, but it's really not necessary now. But it is worth asking your developers if your webhelp could be auto-built in the same way as their generated executable code. In the longer term, this would make your life (and theirs) far simpler.
Marjorie
My goal in life is to be as good a person as my dogs already think I am.
My goal in life is to be as good a person as my dogs already think I am.