MadCap Software Forums

Having successfully imported our old projects into Flare, our team is now integrating Flare with PerForce. Any guidelines, tips, or tricks would be most appreciated.

Thanks in advance!

Our TOCs get corrupted when checked out and checked back into Perforce. I think this is due to a lack of unicode support on Perforce's end. Make sure to back up your TOCs after editing them. Please post if you encounter this problem as well.

Thanks,
Dan

We use Perforce as well and I have not encountered problems with submitting files; however, we customized it so that help files are synched to the workspace.

My company is thinking of using Perforce for our documentation department. We have two writers. One writer is in the home office and I work 1500 miles away remotely. Have any of you found that Perforce helps your working environment and is there anything you've come across that we should watch out for? I see there was an issue with the TOCs has it been resolved or do you just work with it? Any feedback would be great.
Thanks!

You want to be sure that you have your source Control Program use binary settings so it won't change Text files.

Does Flare have any white papers or similar information on integrating with Perforce, or on its performance
with other source code control systems?

Right now I pick up my output from Windows Explorer and scp it to my Perforce workspace before I
check it in. Management would prefer a trail documenting every version of the help system, which
would be okay if there were a reasonable expectation that it would work flawlessly.

I don't get that from the 2 Forum topics. I haven't code-controlled the development files because I am
worried about delays and corruption - probably like everyone else.

So -- is there ANY more information from Madcap on source code control of Flare?

Currently Flare Works with VSS and Team Foundation Server, It will work with other Source Control Providers, If you use one of thier windows Plug Ins, Thier Plug ins must be Fully MSSCCI.API compliant, We have tested with the software from Pushok.com.

After playing around with the Source Control interface, I have observed that while it is easy to set up it slows down project performance to an absolute crawl and is pretty unusable at this point. You cannot scroll through the list of files in the Content Explorer, for instance.

I'm going to submit a ticket on this, but does anyone have any suggestions to speed up the performance?

We gave up on source code control from Flare. I am now submitting my Flare output (only) in the form of two zip files. The GUI team created an interface from those files to the application to maintain the CSH links.

Our source code control administrator consulted with Perforce before deciding that it just wasn't going to work any other way.
Besides the latency problems, Perforce can't handle filename changes and deletions, and I do a lot of that.

So my development files aren't version controlled and won't be. Now they're asking me to find a place to put a version and date in the output
by hand.

I'm working on it.

Bee

I submitted a bug regarding this. Once you bind a project, after you shut down Flare, the flare.exe process continues and takes over your CPU.

I have experienced the same bug as reported by WordGeek on 8/22/07: flare.exe stays around and takes over the CPU (50% of cpu on a dual-core processor).

I tried binding my Flare Project(s) to Perforce but the slow down rendered it unusable. Now all I do is every Friday run a Revert Unchanged Files and then Check in (and straight back out) all my other files in Projects I've been working on. This seems to work well so far and I have the peace of mind that it's being backed up to tape should something hideous go wrong.

In addition, binding to Perforce does appear to cause one instance of the flare.exe process to hang around rather than be disposed of (bug was submitted earlier this year). This has a rather detrimental effect on memory and performance as you can imagine so I just stick with the above solution which works for me. I've not had any problems with Perforce corrupting my files, in fact I'm really rather fond of the two programs, but they do not play well together.

I want to add my experience to this list in the off chance that someone at MadCap will read this and something can be done to resolve this issue.

Specifically, in response to tommyspoon's posting from Tuesday, Aug 21, 2007 at 12:52 pm, I have exactly the same problem: I bound my Flare project with the Visual SourceSafe, and now my project has slowed to an unbelievably slow crawl. Granted, my help project is gigantic (2,342 objects in just the Content folder alone), but I'm also wondering if it's because my company (God bless them) is frugal and is using [a dinosaur!] Visual SourceSafe V6.0c.

I have a team of three writers here and we really do need version control on our project. It's so big it's really difficult to use any manual means of preventing us from overwriting one another's work.

I'm interested to know if anyone else has experience from which he or she can draw a comparison. The slowdown on our files is absolutely miserable. Suggestions for other methods of version control are also welcome.

Make sure you submit a bug report. This is a peer-to-peer forum that may occasionally be visited by MadCap Support. When you submit a bug report, it goes through the official channels. Plus, the more people who report a problem or request a feature, the more likely and sooner MadCap is to fix/implement the change.

There are other threads on the Perforce issue.

Binding in Flare does not seem to be resolved. I last tested it with Flare 5.0, with the same results as reported by other posters.

As I see it, the upshot is:

Don't try to bind your Flare project to Perforce - although it seems to work, it has several difficulties, including:

• Doesn't remain bound
• Can't handle deleted or renamed files (since renaming entails deleting and adding)
• Remanent flare.exe after closing Flare
• Performance issues

However, Perforce works fine if you manage your files manually:

• Check out the whole project before working
• When you've finished, Revert Unchanged and submit the changed files
• Remember to Add and Delete files manually, including new topics, graphics, renamed files, snippets, stylesheets, targets, master pages, etc.
• Perforce will support multiple users of the same file; use Perforce's Merge tool when submitting.

Tips:

• Do not submit the Analyzer folder
• Submit the TOC as binary (I'm looking into this right now - Perforce changes the UTF setting of the .fltoc text file, so if you have trouble you have to change UTF=16 to UTF=8)

We've been using Flare and Perforce for more than a year now, and, once we established a process, it's no trouble at all.

Having said that, RoboHelp can integrate with Perforce (its one and only advantage, IMO), so I hope it reaches the top of the Madcap developers' To Do list.

See also http://forums.madcapsoftware.com/viewto ... =13&t=8765

If you are sharing fltoc files, submit them as binary.

Mishou6779 wrote:I want to add my experience to this list in the off chance that someone at MadCap will read this and something can be done to resolve this issue.

Specifically, in response to tommyspoon's posting from Tuesday, Aug 21, 2007 at 12:52 pm, I have exactly the same problem: I bound my Flare project with the Visual SourceSafe, and now my project has slowed to an unbelievably slow crawl. Granted, my help project is gigantic (2,342 objects in just the Content folder alone), but I'm also wondering if it's because my company (God bless them) is frugal and is using [a dinosaur!] Visual SourceSafe V6.0c.

I have a team of three writers here and we really do need version control on our project. It's so big it's really difficult to use any manual means of preventing us from overwriting one another's work.

I'm interested to know if anyone else has experience from which he or she can draw a comparison. The slowdown on our files is absolutely miserable. Suggestions for other methods of version control are also welcome.

For VSS, what I ended up doing was going back to the old fashioned way - i.e. check files in and out of VSS using the VSS client then opening them in Flare rather than letting Flare communicate with VSS directly. When I did connect Flare to VSS, it basically flooded the server with packets, which killed it as far as other VSS users were concerned.

The fact that Flare still does this 2 years later suggest to me that Madcap doesn't have their documentation bound to the same source control server as their code....