Perforce and Flare

[Andrew Heard]

Thanks for the tip. Will look into it.

[samjones6]

Hey, poking around, just found this:

http://public.perforce.com/wiki/Perforc ... ne_Recipes

more:

http://www.exemplics.com/node/2

Some useful stuff there.

[msutton]

Hello. I am new to Flare, but I'm having the same issue.

I am one of three writers in my group, and have just been assigned to a product team (I am a new hire). The Flare project was previously maintained by another writer. We use Perforce for source control. I can check the files out of Perforce and open them in Flare 7, but when I try to open any file - TOC, content, anything - I get the following error:

"The file <filename> contains invalid XML. Data at the root level is invalid. Line 1, position 1. Do you want to open as text?"

The error is the same for every file - same line and position number. I can open these files as text, but that is not particularly helpful, as I don't want to edit XML.

Does anyone know how to fix this? I've seen multiple references on the forums, but I can't seem to find a solution.

Thanks.

Mary Sutton

[Michele]

There is a control character on the first line. If you open the file i a text editor, you will see what I'm referring to . . . unfortunately, you will have to open each file and delete the character(s).

Also, go into Perforce and make sre your TOC is the text file type. If it isn't, right-click on the TOC name, select Change File Type, and select Text from the drop-down then submit.

[Elizabeth]

I'm another user relatively new to Flare, and a solo tech writer. Our development team uses Perforce for source control, so I'm using it, too.

The part I can't find information on is: Which Flare project directories should be included in source control, and which should not be included? We included the entire /Content directory. We are already excluding the Output directory, since we can generate its contents from the files we do check in.

But what about the /Project directory and its subdirectories? Should those directories be included in source control, or excluded from it? For example, should the /Project/Users directory be included in source control? I found that unless the RecentLinks.xml file in /Project/Users/<myName> is read/write when I build the project in Flare, the build generates lots of errors and cannot complete. Does that mean I should exclude this directory from source control as the means to ensure that the RecentLinks.xml file is always read/write? Or should I include it in source control and then ensure I check it out before running a project build?

Also, does the output of the build of a project depend on any of the per-user settings found in the /Project/Users directory? We want to automate the Flare project build as part of the script that builds our application, and the question was posed as to whether the build output is in any way dependent upon per-user settings.

Thanks!

[RamonS]

Everything except for the output directory should be added to source control. As far as project wide files, you need to check those out when making project related changes and as it seems making builds.

[LTinker68]

Everything except for the output directory should be added to source control.

I don't think you want/need the Analyzer folder either.

[Madcap Guru]

Ther output and Analyzer folded don't need to be in source control, The output will be changed everytime you Generate Help, The Analyzer folder will be updated when you start Flare

[Msquared]

once Flare has frozen, it hangs when re-opened; to open:

1. kill Flare process
2. open without connecting to Perforce
3. unbind
4. re-bind

Thank you so much Andrew. I've been struggling with Flare and Perforce for some days now. This was the key for me. I am now hopeful that I've got Flare and Peforce talking to each other, albeit with a bit of ongoing supervision on my part, and some "features" that I avoid since they cause Flare to hang.

I am also making liberal use of Source Control > Refresh to ensure that Flare is in sync with the actual Perforce status of a Flare file, and Source Control > View History to see what the Perforce status actually is. From the Perforce View History display, you also have access to most of the Perforce functions directly, on a right click. This seems to give me the best of both the Flare integration (invaluable for situations where changes to one file have a knock-on effect on others inside Flare, and for deletions and renames which must be done inside Flare to ensure links are correctly updated) and direct access to Perforce.

Incidentally, although our developers love Perforce as a source control tool, they also have difficulty integrating Perforce with their development environment. They tell me that one of the problems is the specification of the Microsoft SCCI API - that's the source control interface specification that Flare has to meet and that the Perforce P4SCC plug-in has to implement. They have tried both the generic P4SCC plug-in, and plug-ins specific to their development environment. If hardened developers can't get it to work for them, then perhaps we shouldn't be too hard on Flare.