MadCap Software Forums

I see that others have posted on this issue before, so I am just posting this in the hope that somebody may have found a good solution or workaround.

Our experience is that once a Madcap project reaches a reasonable size, switching between git branches becomes more or less impossible - Madcap becomes unresponsive for many minutes. In many cases, it interferes with the screen refresh process, leaving patches of the Madcap UI obscuring other application windows, so you can't even work on something else while waiting. The only way out if this happens is to terminate the Madcap process.

The same problem occurs if, instead of using Madcap to change branch, you change branch on the command line or using an external tool. The branch change itself is performed without any problem, but Madcap hangs. So it appears that it is not changing branch itself that causes the problem, but that Madcap hangs while adjusting to the new context.

More specifically, it seems to be not Madcap itself that hangs, but the Madcap source control extension. In other words, you can completely fix the problem by unbinding the project from git and only using the command line or an external tool for git operations.

This problem makes the Madcap git extension more or less unusable for us - unless somebody out there has a workaround we haven't thought of, or that a fix is planned for the near future.

Wish I had good news for you... We have given up on the Git extension for Flare, and just use an external tool to do all git operations.

Even then, switching branches is a bit of a struggle while Flare is open (I assume because it's trying to work out what to display to you, recalculate all the links between objects, etc). Typically I close Flare, switch the branch, delete the Analyzer folder for good measure, then open up Flare again.

My colleague and I had the same problem for more than a year, and it was driving us mad. Especially because the last person in put team experienced no problems at all.
We were about to give up, when we started to compare the hardware on our computers. I turned out that the colleague that had no problems at all, had 64 MB RAM memory on his computer, whereas my computer had 8 MB RAM and the other colleague's computer had 12 MB RAM. We changed the two PCs to computers with 32 MB ram, and since then everything has been running completely smooth.

We don't use Flare's git integration as it is unreliable. Our content is on an internal Bitbucket server and we use that and Sourcetree outside of Flare. We're waiting for a fix/improvement to the latest release before upgrading as well.

CharlotteStiboDX wrote:My colleague and I had the same problem for more than a year, and it was driving us mad. Especially because the last person in put team experienced no problems at all.
We were about to give up, when we started to compare the hardware on our computers. I turned out that the colleague that had no problems at all, had 64 MB RAM memory on his computer, whereas my computer had 8 MB RAM and the other colleague's computer had 12 MB RAM. We changed the two PCs to computers with 32 MB ram, and since then everything has been running completely smooth.

@CharlotteStiboDX I hope that you meant to write GB instead of MB - 8MB is the minimum recommended RAM for Windows 95!

But more seriously, that is a very good point, if you're having trouble with a program or specific intensive operations it's always worth checking whether you have enough RAM to do the job.

I have a workaround for the branching issue that I devised long before Flare even had the functionality to switch branches and before Central existed. This workaround might have some applicability for you...

I have multiple copies of the project on my computer. One copy points to master/main. Other copies point to specific branches. So say we need to start working on v2 documentation. In the remote repo (e.g., Bitbucket, Github), I'll use the platform's functionality to create a branch. Then, on my computer, I'll set up a v2 folder to sit "beside" the folder where the main project sits. With Flare, I'll import from the repo. Once the project import is complete, I'll then use Flare's functionality to switch to the v2 branch. At this point, switching should take very little time because we haven't yet started making v2 changes. Going forward, I just have to be very mindful about which folder I'm working in. Typically, I don't touch main/master at all.

But what if an authoring team member needs to get the v2 branch long after we've started making changes? Well, same process, except that they might have to wait -- quite a while -- for Flare to switch to the v2 branch. But they have to go through that pain only once.

BTW, I handle the merges in the platform rather than Flare, too.

I have no idea if this workaround is viable if Central is involved. This workaround was devised long, long before Central existed.

Also, I realize that this workaround of having multiple copies of the project might not be manageable for authoring teams that have lots of branches, such as for individual features.