Issues with pulling / pushing from Central since upgrading to Flare 2023 R2

[writer-sam]

Hi there Flare & Central users!

Is anyone else experiencing issues in Flare since the upgrade to 2023 R2? I have some projects where myself and another team member are both working on the same project but not the same topic let alone the same folder. Everytime we attempt a pull from Central, we get merge conflicts for files neither of us have touched - the CSS, masterpage, random HTM files. It's gotten to the point of when we're in the largest project, it's easier to pull a clean version into a new local folder rather than update our existing local version, and just remove our old local copies. Push, although taking an age now, seems to be mostly OK. Only once so far have I had to pull a clean version, manually copy my updated HTM files into the new folder and complete the push. We're the only ones in our wider team that are currently sharing a project since we all upgraded and are the only ones experiencing this. We've been working in the same projects for nearly 3 years now so it's not a case of "needs training".

Has anyone else seen this? Just want to check before I go to Flare themselves.

Thanks in advance.

[AlexFox]

I had an issue yesterday where shortly after a commit Flare reported that my project had been deleted from Central. After an initial panicked check that it was all still indeed there, I phoned support and managed to fix the problem with the following steps:

Renamed the local project folder to "projectname_bak"
Installed Git for Windows (follow the link in Flare's File > Options > Source Control dialog)
- The Git installer has a lot of options but you can safely stick with all the default options.
Close and reopen Flare, verify installation of Git by checking the File > Options > Source Control dialog again.
Using the Flare Madcap Central pane, import a new project
Import the project in question using the same project name as before

The combination of importing the files from Central and having Git for Windows installed seems to have resolved whatever Git issues are being caused by Flare's Git implementation and I haven't had any issues since.

HTH.

[AlexFox]

Seems the Flare forums block any attempt to edit posts so just to clarify when you import the project from Central, keep the name as is.

[writer-sam]

Thanks AlexFox. That's interesting that having an instance of Git seems to resolve it. We're locked down as to what we can install on our work devices but will certainly give it a go and report back.

[Frank_Finnegan]

Just like writer-sam, I too have experienced pull/push issues with Flare 2023 r2, but mine are with Flare and GIT, not Flare and Central.

Perhaps the two issues are related?

As well as seeing lots of merge conflicts at times, there are other times when I pull from GIT and Flare reports that all files are up-to-date. However, I can see in the Bitbucket repository that there are newer version of the files. I can't pull those new files from GIT because Flare thinks my local version is synchronized.

I've had to resort to install a fresh version of the project on my local drive so that the fresher files are downloaded. It's a pain to have to do this, especially when collaborating on shared projects.

[writer-sam]

Hey Frank_Finnegan,

Central is based on the GIT architecture so it makes sense you're experience similar issues. I have logged a call with MadCap so will report back here if a resolution is found.

[Frank_Finnegan]

I have logged a call with MadCap so will report back here if a resolution is found.

Thanks writer-sam. I'm hoping for some good news.

[stijnvanderwee]

Hello all,

In our multi-author projects we had similar push and pull issues with Flare 2023 r2. However, running Git for Windows has fixed this. We can push and pull our commits as smoothly as before again!

Am curious to know though if there is any news from Madcap yet on a more structural resolution?

Best regards,
Stijn Vanderwee

[writer-sam]

Hi everyone,

Thank you for all your suggestions. I've been discussing and testing with their Support team and it looks like Git for Windows is the way forward with this issue. No other structural resolution.

When installing Git, make sure HTTPS transport backend is set to Use the native Windows Secure Channel library setting as per MadCap's instructions:

Git-installer-settings.png

All other settings can be left as default. If HTTPS transport backend is set to User the OpenSSL Library, the problem persists — @Frank_Finnegan, this might be your problem here. Note, I installed the latest Git version - 2.43.0-64-bit

MadCap have also kindly provided me with the following so I can justify why my designers need this addtional software:

1. Enhanced Efficiency and Collaboration: Git is a cornerstone in modern software development, facilitating efficient version control and collaboration. It allows multiple team members to work on different features simultaneously without interference, significantly speeding up the development process.
2. Industry Standard: Git is the industry standard for version control. Its adoption puts us in line with best practices and makes collaboration with external partners more seamless. This standardization is crucial for maintaining competitiveness in our industry.
3. Improved Code Quality: Git enables detailed tracking of changes, making it easier to review updates and maintain a high standard of code quality. It supports branching and merging, allowing for experimental development without risking the stability of the main project.
4. Enhanced Security and Backup: With Git, every clone of the repository is a full backup. This decentralized approach enhances security and reduces the risk of data loss. Moreover, Git’s robust permission and authentication features align with our organization's security protocols.
5. Cost-Effective and Open Source: Git is open-source and free, eliminating licensing costs. Its active community ensures continuous improvements and availability of extensive resources for troubleshooting and learning.
6. Compatibility with Existing Tools: Git integrates seamlessly with many tools and platforms we currently use, enhancing our existing workflows rather than disrupting them.

Hope this helps others

[Frank_Finnegan]

Thanks for the follow up, writer-sam.

I will advise all of our authors to install GIT for Windows.

Regards,
Frank.

[JRtechw]

Hi Writers,

Thanks for bringing this issue to Flare users' attention. We've been experiencing this issue since upgrading to r3. I have a couple of other troubleshooting steps that may prove useful.

Rather than reinstalling Git for Windows and selecting the alternate Backend Transport option, you can use the Git Bash console to manually update this configuration setting.

We are on Git for Windows 2.34.1.windows.1, so a slightly older version than the example shown, and the fix still seems to hold up.

1. Open git Bash. (If you've installed GfW, just type 'git bash' into the desktop search and this app should appear.)
2. Use regular console or prompt commands to navigate to the root folder of the Flare project you want to reset configuration for (cd, cd ..)
3. Type in the following command to check the current configuration value for this setting:

git config --get http.sslBackend
openssl

Note that the 'openssl' line is the return value from git bash.

4. Type in the following command to reset the value for this setting:

git config --global http.sslBackend schannel

There will be no return value from git Bash if the command was successful.

5. Rerun the command from step 3 to confirm the value has been updated. You should get 'schannel' in response.
6. Run a manual git pull and git fetch to make sure the connection is established successfully.

git pull
<response such as 'Already up to date'>
git fetch

------

After that, things seem to be working ok for our collaborative projects.

Note that the --global flag *should* apply this setting to all local git instances, but for a couple of existing projects it didn't seem to stick. But no bigs, we just pulled down fresh versions of those from the remote repo and the setting was preserved for new pulldowns.

You shouldn't need elevated privileges to run these commands.

Hope this is helpful.