Does Robohelp 2019 Classic Integrate with GIT or SharePoint Online?

[Asi2013]

Greetings!

Our company is still looking into upgrading from Robohelp 9 to 2019, and so far we're strongly leaning towards the "Classic" version instead of "Release".

I'd like to get the community's help with the following questions:

GIT:

Does anyone know if 2019 Classic can even be linked to GIT for version control?

And if can't be, has anyone heard whether Adobe plans to make this available as a feature down the road?

SharePoint Online:

We were able to successfully connect RH 2019 Classic with SharePoint Server 2016. Our company may however move to SharePoint Online at some point, and we're worried as to what may happen.

Have there been any hints from Adobe as to whether 2019 Classic and SharePoint Online will be integratable down the road?

Thank you in advance for your help

[Peter Grainge]

I have moved this thread to Source Control.

Look in this forum and I think you will find some posts that suggest that GIT does not always play nicely with RoboHelp.

As to future developments, I doubt that much will change in the Classic versions and expect to see all development focussed on the new UI in 2019.

In the video below, Adobe demonstrate GIT and Sharepoint in 2019.

Home - Adobe RoboHelp (2019 release) – Collaborate using GIT and SharePoint Online

---

See www.grainge.org for free RoboHelp and Authoring information.

@petergrainge

[Asi2013]

Thank you so much Peter!

[Jared Hess]

Hi Asi2013,

I've been investigating RH 2019 as well in some depth. We'll also likely stick with classic if we do upgrade as there are just too many things for us to fix up after my conversion testing to go to the new route. (I'll post my findings later of pros / cons and so on in case anyone else is interested.)

Regarding git support, it's only in the new 2019 stuff. It looks to me that 2019 classic is exactly the same as RH 2017 with perhaps a few bug fixes. I don't think there's anything new in the user interface of classic where you can configure or set it up to work with git.

That said, my team and I been successfully using git as our source control of choice for RH 2017 for a few years now. We use SourceTree as our front end for that. In our setup, we have the master branch. We then use feature branches to document enhancements or bugs. Those get branched off of the master branch. We make edits on the feature branches and then do a pull request to get them merged back into master.

Git is not a source control system that locks the file if someone else is editing it. So, you and your team of authors can all work on the same files and projects and happily make edits clueless of what the others might be doing on the same project. This will eventually lead to collisions with edits from other authors if you're working on the same project. For example, if you're working on the same topic at the same time and you've not pulled their changes, you'll get conflicts. You'll also get conflicts in .fpj files if you add topics and someone else adds topics before you. Same with index entries etc. Things like that. But that's normal, and you can work around those with a good differences compare tool to resolve any merge conflicts and get both authors' edits. We use Beyond Compare for that. You can configure SourceTree to launch Beyond Compare if you hit a conflict.

You will also want to decide what files to track and what files to just keep on your own system. You can use the .gitignore file that your git repository provides to define what to ignore. Things like temporary files you'll want to ignore (like your SSL folder) so that they don't always keep showing up. Also, any user-specific settings you'll not want to track.

Shared resources might be something to watch out for to. Your mileage might vary, but for us, we started using git and shared resources. Everything works great until you update to a new branch, then suddenly your source on your computer is different than it was, but shared resources hasn't changed and it thinks it needs to copy down updates. We ran into so many headaches with shared resources that we eventually completely disabled it and share many things manually. While human-error prone, it seems a marginally better solution that the types of issues we had with shared resources.