Use Subversion as Source Control

We have tried using RoboHelp collaboratively as follows:

1. Moving the project directory to a network drive. This resulted in VERY slow performance, which was almost okay, until the data became corrupted and we had to abandon a bunch of work because it was unusable.

2. Putting the project directory in subversion and checking it out again on another workstation. This resulted in the subversion "hidden" directories confusing RoboHelp and making it think there was a bunch of 'baggage' files that weren't really that at all. This is another form of corruption and we are not doing it that way.

Our New Plan is to:

3. Create a VMWare VM running XP (cheap) with RoboSource Control 3.0 (free) on it. This will require an installation of MS SQL Server Express (free version of SQL server). We're doing this on a VM because we're not going to be significantly taxing this box with only 3 people hitting it for version control.

We will have this VM run a scheduled task to back up the SQL Server database regularly and put it on a regularly backed up network drive.

Problem solved, inexpensively, using tools that are already integrated with RoboHelp.

-- Kevin J. Rice, Textura Corp.

We have tried using RoboHelp collaboratively as follows:

1. Moving the project directory to a network drive. This resulted in VERY slow performance, which was almost okay, until the data became corrupted and we had to abandon a bunch of work because it was unusable.

2. Putting the project directory in subversion and checking it out again on another workstation. This resulted in the subversion "hidden" directories confusing RoboHelp and making it think there was a bunch of 'baggage' files that weren't really that at all. This is another form of corruption and we are not doing it that way.

Our New Plan is to:

3. Create a VMWare VM running XP (cheap) with RoboSource Control 3.0 (free) on it. This will require an installation of MS SQL Server Express (free version of SQL server). We're doing this on a VM because we're not going to be significantly taxing this box with only 3 people hitting it for version control.

We will have this VM run a scheduled task to back up the SQL Server database regularly and put it on a regularly backed up network drive.

Problem solved, inexpensively, using tools that are already integrated with RoboHelp.

-- Kevin J. Rice, Textura Corp.

I agree that the "solution" is a detraction; it requires you to keep the output in two places on your hard drive. Version 7 is in beta--not released commercially yet, but supposed to be sometime before the end of the year.

I think I have that same problem. When I generate my projects that I use Subversion with, the .svn folder in each directory is still there, but when I try to commit, it throws an error and says it can't find a file in the "tmp" folder. My workaround to this point has been to copy any changed files to another location, delete my output folder, update to get the last version, and put the updated files in. That's the only way I've found that Subversion will accept my changes.

I just googled to find more on this topic, and the only thing on this problem I found was this page:

http://svn.haxx.se/users/archive-2006-02/0937.shtml

The solution, the reply says, is to generate your project to a folder that is not under version control, which means you have to copy the output and paste it into your version-controlled directory, then commit to the repository. Fun. A little simpler than what I've been doing, at least...

--Ben

We found that compiling the project deleted files and folders in our hidden .svn folder which is needed for subversion to work. Anyone know how to resolve this problem?

If I could just pipe up here, too, since we also use Subversion. In case you need any more information about Subversion, you need to install a client like TortoiseSVN, SmartSVN, or the Subversion command line before it will work. Then you use that client to check files into and out of the repository. As Amy noted, this is independent of the RoboHelp interface. Each client should have documentation, or a developer can probably get you set up.

If you haven't done so already, you may want to talk to the dev lead or similar individual to find out where in the repository he/she wants you to keep your files. I have been asked to keep the source files (the directory where I keep the .xpj file) separate from the directory where I have the generated output, which is included in the builds and deployment. The developers don't want a bunch of extra stuff included in the deployed files.

What do you mean by "set up", in this context?

I use Subversion with RoboHelp, but I didn't do anything to RH to achieve this. Workflow is:

1. 
   
2. Set up svn module(s) for documentation contents (once per module).
   
   
3. Check out manual sandboxes (once per user) - happens from command line or in windows GUI, RH not involved.
   
   
4. Commence regular usage pattern:
   
   • 
     
   • When you have changed or added a file, check it in (according to your local checkin policy, which might require things like HTML validation before checking in, and might specify what kind of frequency is reasonable). RH not involved.
     
     
   • Do svn updates periodically.
     
     
   • When you want to build the documentation, check out a clean copy and do the build.