RoboHelp integration with Git version control

[Jop_Smith]

Does anyone know if RoboHelp 9 can be integrated with Git version control?

My company is thinking about switching from TFS to this open source product, but I need to make sure that it is compatible with RoboHelp. I can't find a definitive answer on the web, so I wondered if anyone on the forum has had any experience of it?

Thanks

Jonathan

[RoboColum_n_]

Hi Jonathan.

RoboHelp traditionally works with any source control application that uses the Microsoft SCC API. I am completely unfamilar with Git so I think the best way to answer your question is to ask them if they use the API. If they do, you should be OK. However there is bound to be some setup involved and as you've found out there isn't a lot of info out there on it.

[Jop_Smith]

Thanks Colum.

I've fired off an email to Git so I'll see what they say and report back.

[kmaddox1]

Hi Jonathan,

First of all, let me acknowlege that I am not a source control expert. So what I'm describing below may not be technically correct. All I know is that our s/w development  team switched from Surround (SCM) to GIT last spring and the Tech Pubs group unwittingly went along. It didn't work for us. The biggest issue we had is that GIT doesn't lock (check out) files that are being worked on--everyone who is working on the same Robohelp projects has  writable copies of all files on their hard drives. While that approach works if you are disciplined about only working on your specific projects, we ran into merge conflicts if both writers inadvertently made changes to the same help project within the same time frame.

GIT provides no mechanism to prevent this and the issue is compounded because of the way Robohelp manages files--it changes some files behind the scenes even when all you did was to open a project and publish it to a different location. We spent lots of time trying to figure out which writer's version of these changed files were the "right" ones and which ones could be overwritten. In some cases, we resorted to emailing known good files to the other writerin order  to avoid having to use GIT's diff tool to resolve line-by-line differences.

That said, if you get good GIT training and if you are more source-control savvy than me, you may end up loving GIT like our developers do. In our case, the developers pretty quickly got tired of helping us figure out merge conflicts and agreed to let us go back to using Surround. We are much happier now.

Hope this helps,

Kathy

[Jop_Smith]

Hi Kathy, thanks for sharing your experience of Git. I'm no source control expert either, but it sounds Git isn't great at "talking" to RoboHelp!

As Colum pointed out "RoboHelp traditionally works with any source control application that uses the Microsoft SCC API". However, after some digging around it appears that Git by itself doesn’t know anything about the Microsoft SCC API. Apparently, this is partly because Git is not a Windows DLL, but rather a bunch of executable programs, with its development originated in the Linux world. However, a reply to my post on the Git forum suggested that there may be a commercial product that provides a “wrapper” for Git exposing this API - which I Googled: http://www.google.com/search?q=Microsoft+SCC+API+Git.

We may be better sticking with RoboSource Control instead and leaving Git to the developers.

Thanks again

Jonathan

[kmaddox1]

yes, I'd say that if RoboSource Control is working for you and you aren't being forced to move to GIT (as we were), stay with what you have.  I am unable to find the emails I sent to our Dev group documenting the issues we found after switching to GIT, but I do remember that some of the problem had to do with the .apj files that Robohelp uses for things like build tags, colors, keywords, templates, and so on. If both writers were working in a project and one of them changed something that affected one of these files, the other writer could get a merge conflict when trying to push the RH files to GIT. It was not easy to determine whose version of the APJ file was the one to use  or to merge the changes into a single file. As a result, we ended up doing informal file checkout--yelling over the cube wall to say "hey, I'm going to be updating this project. Please stay out of it for the next few hours."

I'd love to hear from anyone who does successfully use GIT with Robohelp. I'm sure a lot of our issues had to do with our ignorance of how we were really supposed to be using the tool.

[JDShelton09]

Kathryn, We are currently using TortoiceCVS, and we have to use email/chat to let authors know when we are in a project. Not the best use of technology. We aren't high on the food chain as far as being inconvenienced by the SCM. Our developers are probably going to use Git, and I was hoping that would change, but apparently not.

[kmaddox1]

Hi Jan, Good luck with that. I would advise you to talk to whoever in Development is spearheading the move to GIT and make sure they know that it may not play well with Robohelp. Maybe there's something they can do to help you avoid the types of issues we were experiencing. At least make your concerns known up front ...

[JDShelton09]

The head guy says if we are producing source code (which we are), it needs to be in the same SCM as the app code. "Particularly if you are going to bind a version of that code to the rest of the source code." I am sure he is correct, but that still leaves us emailing back and forth, as we are now. It isn't hat big a deal, since we are used to it, but it might become a big deal if Git handles changes worse than TortoiseCVS does. And from what I'm reading on this forum , it does.

I briefly checked out a "wrapper" plug in for it, but that involves spending money, which our company isn't likely to do.

But you are correct. I will present my concerns and articles from this forum up front so perhaps we can get a head start

I would like to use RoboSource, but have never had the opportunity to.

Thanks for your quick reply.

[Jeff_Coatsworth]

@jan - I highly doubt that you are producing source code in the same meaning that your developer is ;>)

Your RH projects are a bunch of Access database files and some JavaScript flavourings all producing HTML pages with JS gluing them all together - your WebHelp output is what's being "bound to a version of the code" the developers are producing.

[JDShelton09]

Good point, Jeff. I guess I was generalizing that term since we "compile" the files into a usable form. I will relay your description to the head developer dude. That might explain things better for him.

[Jeff_Coatsworth]

If anything, you probably want to use RoboSource to control your projects and Git to handle the output so that what you produce matches what the developers are creating.

[JDShelton09]

Thank you for the suggestion Jeff. I would like to use RoboSource, but getting a server around here is like the proverbial hen's teeth. But I will definitely bring it up.

We currently use AccuRev for housing the output. I am not sure they want to stay with that tool if they are moving to Git. But I will defintely ping you when they are further along and I need more technical details.

[Jeff_Coatsworth]

I'm a one-man band around my shop - better to post over in http://forums.adobe.com/community/robohelp/robosource_control for all your source control questions.

[JDShelton09]

Will do. Thanks again Jeff.

[JewelyaZ2]

It's 2017 now, but Adobe still hasn't done a thing to make RoboHelp interface with Git, which is one of the industry standards for source control if not THE most common solution. This is one of many things that is driving us to move all our content to MadCap Flare. As founder of my company's technical communication guild, I am working to move all the lone writers here to Flare also. 

I will be waving a somewhat sad goodbye to RoboHelp by the end of 2017. I have been a user of RoboHelp since version 1.0 in 1990, when it was still being sold and supported by its original developers, Blue Sky Software. Adobe just isn't supporting the software with fresh innovations... and if they can't address questions like this in four years, I really don't feel any further obligation to argue to keep the product in our lineup.

Too bad.

Julia

[johndaigle]

Wow, I really hate to hear this, Julia. I too, have used Rh since version 1 and am enjoying RoboHelp's new Dynamic Content Filter feature technology which neither Flare nor any other help authoring tool has. I have reached out to Adobe engineering to see if there is any news regarding GIT integration and will let you know if there are any changes coming soon.

BTW, if you are in Tacoma, Washington this September 7 and 8 for the Writers UA Tech Comm conference, please find me to say hello. I'll be speaking at two sessions:

The Tech Comm Conference

Thanks

John

John Daigle

Adobe Certified RoboHelp and Captivate Instructor

Evergreen, Colorado

www.showmethedemo.com