Madcap Flare and Source Control in the Cloud
We’re doing a conversion and clean up project for a client. I recommended that they go with Flare because it met their needs well at a price they can afford. We’re doing the entire convert/clean up thing offsite and when we’re done, we’ll hand the entire project over to them.
And, of course, because this is the way it works, the client may need access to some of the files for an urgent project no one saw coming. So they may need access to the source files before we’re ready to hand them over as complete.
And they have no way for us to put the files in their source control so that we have access to the project outside the firewall.
My brother to the rescue
I talked to my brother about setting up a Subversion repository on my website (he’s smart and you should talk to him if you need a website. He hosts mine because I’m the sister).
Subversion was the right choice because it’s free and Flare has internal connections to it. He investigated and, while it was possible, would take more of his time that he had available for his little sister at the moment.
“Why not use a cloud solution?” he said.
“Cloud solution? I had no idea.” I said.
Why, yes, Subversion cloud solutions exist
I did some research and found CloudForge. It has a free 30 trial and the support was excellent as I got set up. I’ve not worked in Subversion before so there was some learning for me. But the interface was easy enough.
The inexpensive repository size for us is good and the price will be quite reasonable after I hit the pay period. A good solution overall.
And then Madcap’s support team rocked
In Flare, I was able to bind the project and upload the large number of files. I worked on my machine and life was good.
Then I tried to set up my staff and we ran into huge problems. We could not get Flare to finish downloading the source files. It stalled out about a third of the way thru, utterly defeating the reason we’re using Subversion. All of us have to be in the files at any given time.
After spending a day working around and thru it with the CloudForge people and my skills, we reached the conclusion this was a Flare issue. So, Monday morning, I handed it over to Madcap Support.
Rob spent the better part of a day figuring it all out and got us going. In the process, we discovered and reported a bug.
In fact, Flare was downloading the entire project but it stopped reporting that it did. If we waited and then blew Flare up, when we opened the project, Flare continued on building the source control stuff it needs.
It all works and I’m very happy
I wish the story was more about me and how wonderful I am but the heroes of this story are my brother (Hi, Dave!) and support (Hi, Rob!) at Madcap. The part I’m delighted with is this all works now, just as expected and in a seamless way.
This is why socializing your problems can often be a great idea. Other people have brains with information you don’t have.
And the result? I’m happy!
There is an easier way when you want the same image to aeppar multiple times, like a special bullet. I worked this out with MadCap support. It involves using a graphic as a background image. The following is an example of one of many styles I created using this method:p.Image_left{background-image: url( ../Images/image.gif’);background-repeat: no-repeat;padding-left: 24pt;padding-top: 0pt;min-height: 18pt;}Your padding-left will vary depending on the size of the graphic you use. You also must use the min-height for graphics that are larger than a single line of text for those cases when you only have a single line of text. Otherwise, the bottom of the graphic will be cut off.Also, everything about the above method works for PDF output, as well as the online outputs, except for the min-height property. So you can use it for PDF output only if you are sure you will have enough lines in each paragraph to match the graphic height.
Thanks Sharon. That might work well for a new client of mine too 🙂