Return of RoboSource?

If you used RoboHelp in the X5 days, you may have noticed RoboSource Control - the free version control system that shipped with RoboHelp. It was so simple that many people who saw it had the same initial reaction - "a toy version control system." But that reaction was wrong. RoboSource made version control simple enough that it didn't take your focus away from the actual project work.

Unfortunately, RoboSource 1 had problems. One bug corrupted a RoboHelp project if you added it to version control through RoboSource, but you could add the same project to version control just fine through RoboHelp. There was also a limit to how many files RoboSource could handle. A rule of thumb was to expect problems if a project neared the 2,000 file mark and to be surprised if you didn't get problems above 2,000 files. (2,000 seems like a lot, but consider a 1,000 topic project plus screen shots and you'll see that files add up quickly.) Finally, the documentation wasn't clear, so many people never tried it because they didn't understand how it worked in the first place. And RoboSource just dropped out of sight during RoboHelp's time in limbo under MacroMedia.

When Adobe released RoboHelp 6, one feature that was lost in the uproar was a new version 3 of RoboSource. (Adobe kept RoboSource 3 when it released RoboHelp 7.) I ignored it until three client calls in the space of a month made me go back and look at it again. And helping one client implement it exposed me to some of the internals of the new version and some of its peculiarities.

At a high level, RoboSource 3 works the same way as v. 1. Create the RoboHelp project, then add it to version control. Once you do, there's one other step that has to be performed once. The first time you open a project after adding it to version control, you do so by opening it specifically from the version control system. This creates a local copy of the project on your C drive. From then on, you open the project locally, like you would if the project wasn't in version control. When you do, RoboSource compares the versions of each file in the version control system on the server to the corresponding file on your C drive. If the local version is newer, RoboHelp uses that version. If the server version is newer, RoboSource copies it to the C drive and opens it in RoboHelp. In other words, you're always working on the local version which is being kept up-to-date by RoboSource.

Once the project is in version control, you get the expected check-in and check-out features, along with rollbacks and "diffing" - e.g. "differencing" or comparison of two versions of the same file.

RoboSource 3 still has peculiarities, the biggest apparently still being its file capacity. According to tech support, RoboSource 3 is based on SQL Express so, in theory, its capacity should essentially be unlimited. In practice, however, a client in Florida tried to load a 4,000 topic RoboHelp project (closer to 5,000 files when you count the graphics and control files) only to have RoboSource hang, apparently. This happened late enough in the afternoon that he decided to go home and clean off the server in the morning. But when he arrived the next morning, he found that the project had been added to version control. RoboSource had just gotten tied up with some function the previous afternoon and didn't provide any status messages to that effect, so we thought it had crashed.

In summary, RoboSource 3 is worth a look if you need a cheap and simple version control system. (Do not use the original version, even though it's still available in the RoboHelp 7 toolbox pod.) Try a few small and simple test projects first to see if it's working correctly and, if it is, give it a shot. And let me know what happens...