Use Subversion as Source Control

[bal_logicmanager]

Anyone know how to setup RoboHelp to work with Subversion? All of our development uses Subversion for source control and VSS is way to slow for remote access.

[AmyGfromNZ]

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.
     
   
   

[Guest]

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.

[RoboIT]

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?

[Guest]

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

[RoboIT]

Doing it this way does solve the problem with RoboHelp deleting the tmp directory whenever you compile the project; however, it detracts from the appeal of using SVN since users have to manually copy over changed files to the SVN directory when they want to check in changes. It sounded like AmyG from NZ was using SVN the way it was ment to be used, but maybe that isn't the case (without a workaround). From the sounds of it the RoboHelp compilation process and SVN just don't play well together. Maybe in the Version 7 RoboHelp will keep it's hands off the .svn folder when compiling. Anyone using Version 7? We are on version 6 yet.

[Guest]

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.

[AmyGfromNZ]

The way I'm reading the above, it looks like a lot of people want to keep their RH output in an svn repository as well?

I don't do that. Since you can always recover the generated manual for a given version of the input files by just checking out that revision and building, there is no need to keep the generated manual under version control. If you want to keep the built manual in a place where everyone can see it, it suffices to specify a RH output directory that everyone can read.

The way I do it:

• 
  
• automatic "official" manual builds are triggered by SVN submissions in relevant modules
  
• the resulting "official" manuals are output to a shared (but not version-controlled) directory where everyone can see them (for reference or feedback)
  
• I do "unofficial" builds whenever I want to see what is going on in a manual sandbox and put the output wherever I want, but again it's not version-controlled.
  

The RH command line makes this all so much easier to manage. Hooray for the RH command line.

A

[JustAnyone]

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.

[JustAnyone]

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.

[Ashley_Drew]

Does anyone know if this issue has been resolved in RH 9?

[johndaigle]

This is a older thread. You might take a look at this thread from yesterday which has links to helpful articles regarding Subversion and source control.

Thanks

http://forums.adobe.com/message/3865703#3865703

John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Evergreen, Colorado
www.showmethedemo.com