How broken is Flare 10's native Perforce integration? I did not give up at any one problem. I worked to find the best possible workaround for each problem and the best possible process to minimize the total number of problems. In the end, though, two specific issues made me finally give up:Use Flare for what it's good at (editing/renaming/moving/deleting/adding files), use Perforce for what it's good at (branching/integration/changelists/submits), and NEVER try to bind Flare projects directly to Perforce.
Protip: Use a stream depot for your Flare projects even though nothing is actually bound to Perforce. Stream depot workflow and "merge down, copy up" integration is very intuitive and enforces best-practice mainline development strategies, compared to using a classic depot. The Dashboard view is a great tool for helping authors who aren't SCM gear-heads to stay out of trouble and keep streams in good shape.
In each work session:
1) Use P4V to 'get latest' to your local workspace for a stream.
2) Open the workspace's project file and do all the things you normally do in Flare.
3) Use P4V's 'Reconcile offline work' feature to integrate your changes made during that session into useful Perforce changelists, add informative descriptions to those changelists, and submit them to the associated stream."
Showstopper #1: Even when you set up every stream, workspace, and project binding perfectly, the UI performance in a bound Flare project is abysmally, untenably slow. Just scrolling through a content folder with ~100 files in it (in the Content Explorer) has such incredible lag that it's effectively unusable. I can't imagine how much worse it would be with a laggy RDC connection or for workgroups in other countries who are interfacing with a Perforce server halfway across the world. But far worse is the lag when it comes to some action as simple as a file rename. If you rename a file (in Flare itself) when the project is not bound to Perforce, the dialog that presents you with all the corresponding changes to other files is nearly instantaneous. If you rename a file when the project is bound to Perforce, you must wait an incredibly long time (more than a minute or two) before that dialog appears.
Showstopper #2: If the group administrator who branches a new stream makes one tiny mistake in the depot path attribute of the new stream's .flprj file, authors can easily submit changes to the WRONG stream and never know it unless they're triple and double-checking. Similarly, if any author sets up a workspace in the officially documented way for a stream they've never worked with yet, it's a confusing process that can result in the workspace being bound to the wrong stream without the author realizing it.
If the preceding showstopper issues aren't enough to convince you to stay away from binding projects to Perforce, here's a list of all the additional major pitfalls and issues I ran into during testing, in no particular order:
A. No matter how carefully you set up your workspaces and try to enforce naming conventions that help you organize a diverse set of workspaces across many depots, branches, and streams, Flare ignores them. When you open a bound project file, Flare creates an entirely new workspace with a very long, unfriendly workspace name. It doesn't create such workspaces only if you use the "Import project from source control" wizard; it does this even when you open a project that already has correct binding attributes in its project file. So you're effectively forced to always use the confusingly named Flare-created workspaces instead of your own.
B. The official documented process for "Binding a project to source control" specifically states to (paraphrasing) "Open an existing project in Flare, then use the Project Properties dialog to bind to your desired SCM". There are many problems with this approach for Perforce. For starters, you cannot bind a project to anything other than a mainline stream this way. Second, you cannot add more than one project to a mainline stream this way, because the process tries to put the .flprj file and the Content and Project folders at the root of the stream (conflicting with other Content/Project folders that might already be there from a different project). Also, this method sticks an unnecessary "ProjectGuid" attribute in the project file, which might be needed for some SCMs, but is not needed for Perforce. Having this Windows GUID in the project file makes it really difficult to branch anything off of the mainline stream if you prefer each stream in your depot to have a separately-named project file (which becomes mandatory rather than simple preference due to point "D" below). There's no way to generate a unique GUID for each such project file that is branched off the mainline.
C. Because of "B" above, the only effective/easy way to load a mainline stream with a Flare project and create Perforce bindings in the corresponding project file is to use P4V to add the project to the mainline stream, sync it down to a local workspace, and then run the "Import project from source control" wizard, which will put the correct Perforce bindings in the corresponding project file and leave the file checked out in your local workspace for you to submit back to Perforce. Fortunately, this approach does not plop a "ProjectGuid" attribute in the project file. Unfortunately, due to "A"above, this approach requires you to subsequently delete the first workspace you created for the mainline to get to this point.
D. The "Import project from source control wizard" presents a terrible problem as soon as you start having branched streams in your depot. The official documented process for writers to grab a project from their SCM system tells them to use that wizard. Unfortunately, at one point in the process you're presented with a dialog to select the project file from what looks like an expandable depot tree rooted at the depot level (not rooted at the stream level). Even worse, this is not a proper heirarchical view of the server/depot contents. What you see is a single Content folder, a single Project folder, and one instance of every project file in the entire stream depot. If you don't name your various streams' associated project files differently from each other (which is itself a nuisance when it comes to propagating changes among streams), it becomes IMPOSSIBLE to know which of those multiple project files to choose! Even worse, if you choose the wrong one, your local workspace's copy of the project file will have the wrong bindings pointing to the wrong stream, which means an unwitting author might submit some changes to the wrong stream.
E. You can work around the problem described in "D" above by appointing one person to be the administrator for the stream depot and instituting policy that no one may use the import wizard or any Madcap-official documented process. Instead, your policy would require authors to use P4V to create a local workspace for a stream you want to work with, sync the workspace, and then just open the project file from the local workspace folders. However, this triggers the problem described in "A", which requires further policy that all authors must remember to delete the first workspace they created. Realizing that authors are only human, eventually someone will forget to observe this policy, and the duplicate workspaces that stick around can be problematic in a few ways. One obvious example is that if you open duplicate workspace A and check out a file, then in a later work session open duplicate workspace B instead, you'll be wondering why you don't see the pending/submitted changelists you expect to see, or why you see green-colored checkmarks instead of red-colored checkmarks for checked out files, or why you can't revert some pending changes (because they're pending in the other duplicate workspace).
F. You cannot submit ANYTHING from within Flare itself, because even though the "check in" dialog presents a "Comments" box, these comments are NOT added to the changelist that's submitted to Perforce.