Skip navigation
bal_logicmanager
bal_logicmanager Calculating status...
Currently Being Moderated

Use Subversion as Source Control

Aug 22, 2007 10:52 AM

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.
2149 Views   11 Replies   Latest reply: John Daigle, Aug 17, 2011 5:43 PM
 
Replies
  • AmyGfromNZ
    Currently Being Moderated
    1. AmyGfromNZ,
    Aug 23, 2007 3:01 PM   in reply to bal_logicmanager
    Report
    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:

    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.

     
    |
    Mark as:
  • Ben Minson
    Currently Being Moderated
    2. Ben Minson,
    Aug 24, 2007 1:49 PM   in reply to bal_logicmanager
    Report
    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.
     
    |
    Mark as:
  • RoboIT
    Currently Being Moderated
    3. RoboIT,
    Aug 29, 2007 1:29 PM   in reply to bal_logicmanager
    Report
    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?
     
    |
    Mark as:
  • Ben Minson
    Currently Being Moderated
    4. Ben Minson,
    Aug 29, 2007 2:30 PM   in reply to bal_logicmanager
    Report
    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
     
    |
    Mark as:
  • RoboIT
    Currently Being Moderated
    5. RoboIT,
    Aug 29, 2007 2:47 PM   in reply to Ben Minson
    Report
    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.
     
    |
    Mark as:
  • Ben Minson
    Currently Being Moderated
    6. Ben Minson,
    Aug 30, 2007 6:55 AM   in reply to bal_logicmanager
    Report
    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.
     
    |
    Mark as:
  • AmyGfromNZ
    Currently Being Moderated
    7. AmyGfromNZ,
    Sep 5, 2007 10:04 AM   in reply to Ben Minson
    Report
    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
     
    |
    Mark as:
  • JustAnyone
    Currently Being Moderated
    8. JustAnyone,
    Apr 16, 2008 8:48 AM   in reply to bal_logicmanager
    Report
    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.
     
    |
    Mark as:
  • JustAnyone
    Currently Being Moderated
    9. JustAnyone,
    Apr 16, 2008 8:53 AM   in reply to bal_logicmanager
    Report
    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.
     
    |
    Mark as:
  • Ashley_Drew
    Currently Being Moderated
    10. Ashley_Drew,
    Aug 17, 2011 5:06 PM   in reply to bal_logicmanager
    Report

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

     
    |
    Mark as:
  • John Daigle
    Currently Being Moderated
    11. John Daigle,
    Aug 17, 2011 5:43 PM   in reply to Ashley_Drew
    Report

    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

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)