Does SVN work with RH 8?

[dh2help]

Sorry if this question has been asked before, but does SVN work with RoboHelp 8?

[Robo_Solar]

I think the answer is Yes, but not "out-of-the-box". You need to address some issues to get them playing well together (e.g. choosing a svn client, automating with some scripts, implementing locking on certain files, etc.).

We abandoned RoboSource and switched successfully to SVN some weeks ago.

The initial setup was a bit complex, but now RoboHelp is fast and more manageable than before.

If you need more information, let me now.

[dh2help]

Yes, Please I need more info. We are running SVN 1.4.8 Build 12137 32bit. We have RH 5 and they won't upgrade unless I can get V8 to work with SVN.

[Robo_Solar]

Ok, these are some points we targeted when using RH with SVN.

1) Choose a SVN client. It has to be installed on each pc running RH. We are using TortoiseSVN because it has a good GUI.

2) SETUP SVN SERVER

Install SVN on the server and create a repository, or simply create a folder for robohelp in your existing repository.

Import your RH project to SVN repository.

You have to esclude some files and directory in the root folder which must not be shared among workstations:

.cpd file

c. open RoboHelp project for editing, and when it close:

d. permorm a svn ADD and a svn COMMIT

4) FILE LOCKING.

Implement svn locking for files that should not be modified concurrently. Simply add the 'needs-lock' svn property on them.

Your users will need to get the lock before editing those files. When this happens RoboHelp will show a dialog notifying it needs "write access" on a file. User needs to select that file in windows explorer and use the "Get lock" feature on your svn client. This sounds a little bit annoying but it prevents conflicts and other bad problems in robohelp, and defenitely let you save a huge amount of time.

The locks acquired will normally be released at the next user commit.

The list of files we configured for locking:

ALL FOLDER: *.fpj

ROOT FOLDER: *.h *.css *.ssl *.hhk *.hhc *.glo *.hts *.htt *.htt *.apj robohhre.lng

FOLDER !language!: all files with recursion

FOLDER !skinsubfolder!: all files with recursion

Since folder and files are constantly being added to repository we have written a server script which periodically sets the 'needs-lock' property on all required files.

Optionally you can implemente locking also on binary files like images. We decided not implementing locks on topic files (html) and others. We prefer to face and resolve some minor conflict problem, and not add extra burden to our users. That is a trade-off.

Hope this help. However, this is just our experience, maybe you can find a solution more suitable to your needs.

Regards,

Nicola

[Robo_Solar]

(sorry it seems my previous is not displaying correctly, I'm going to post it again)

1) Choose a SVN client. It has to be installed on each pc running RH. We are using TortoiseSVN because it has a good GUI.

2) SETUP SVN SERVER
Install SVN on the server and create a repository, or simply create a folder for robohelp in your existing repository.
Import your RH project to SVN repository.
You have to esclude some files and directory in the root folder which must not be shared among workstations:
  projectname.cpd
  projectname.hhp
  projectname.pss
  projectname.trl
  projectname.ldb
  eHlpDhtm.js
  ehlpdhtm.js
  $rhvariable$.htm
  !SSL!\

Use the 'svn:ignore' property to prevent these file from being accidentaly added in subsequent operations.

3) CLIENT SETUP
Check-out your project from svn repository to each pc. The path should be identical on all machines (eg: c:\projects\robohelp) If your users are not experienced with SVN, write a .bat script to guide them during a typical session, which should include the following steps:
a. perform a svn UPDATE
b. delete projectname.cpd file
c. open RoboHelp project for editing, and when it close:
d. permorm a svn ADD and a svn COMMIT

4) FILE LOCKING.
Implement svn locking for files that should not be modified concurrently. Simply add the 'needs-lock' svn property on them.
Your users will need to get the lock before editing those files. When this happens RoboHelp will show a dialog notifying it needs "write access" on a file. User needs to select that file in windows explorer and use the "Get lock" feature on your svn client. This sounds a little bit annoying but it prevents conflicts and other bad problems in robohelp, and defenitely let you save a huge amount of time.
The locks acquired will normally be released at the next user commit.

The list of files we configured for locking:
  ALL FOLDER: *.fpj
  ROOT FOLDER: *.h *.css *.ssl *.hhk *.hhc *.glo *.hts *.htt *.htt *.apj robohhre.lng
  FOLDER !language!: all files with recursion
  FOLDER !skinsubfolder!: all files with recursion Since folder and files are constantly being added to repository we have written a server script which periodically sets the 'needs-lock' property on all required files.

Optionally you can implemente locking also on binary files like images. We decided not implementing locks on topic files (html) and others. We prefer to face and resolve some minor conflict problem, and not add extra burden to our users. That is a trade-off.

Hope this help. However, this is just our experience, maybe you can find a solution more suitable to your needs.

Regards,
Nicola

[eddie3721]

Hi Nicola,

I found this link after I encountered some issue w/ RH & SVN.

is it possible for you to elaborate on the reason why these files (#2) are excluded?

I am in the process of adding the rh files for someone in the doc team and the links were broken when checkout from the svn.

steps I did:

1. add & commit all files for my project (ABC) (including the files that you mentioned to exclude)

2. renamed the local ABC to temp_ABC

3. checkout the svn files into ABC

4. open the project file .xpj

5. internal links (to other files) are broken.

thanks

Eddie

[Robo_Solar]

Hi Eddie,

the steps you used to import and checkout seem correct.You should investigate the reason why links are broken. Compare the HTML files between the initial project and the project you checkout from repository: does the link have been changed? or has the target document been moved?

However these are the reason for excluding some files from SVN:

-  projectname.cpd

This seems to be a local cache file. You must exclude it from versioning. We even use a batch to delete it before opening the project, since sometimes RH try to recreate folders which have been removed in SVN but are still referenced in the cpd file. Deleting it can increment RH startup time, but we found it is much safer than keeping it.

-  projectname.hhp
-  projectname.pss
-  projectname.trl
-  projectname.ldb

I think we have been told to exclude these files on a thread on this forum.

-  eHlpDhtm.js
-  ehlpdhtm.js
-  $rhvariable$.htm

We think these are RH temporary files. If RH crashes, these files remain on disk, but we guess they should not be added to versioning.

-  !SSL!\

This is the output directory. Each time you generate the single source layout, RH will clean the directories and delete some local SVN metadata. Your working copy will break. So it should not be added to SVN.

Regards,

Nicola

[dh2help]

Why can't you Publish without Generating first?  Could this be a potential enhancement?  I have to use Publish to get SVN to work, but why do other people use the Publish feature? I have never used it before.

[Captiv8r]

Hi there

I tend to try and explain it like this. Think of RoboHelp like you would a kitchen. You mix ingredients together, then bake them in a stove to end up with chocolate chip cookies. The process of baking the cookies is very similar to generating WebHelp. The source files (cookie dough) go into the oven and bake. (the generation process) Baking the dough changes it, no? Generating WebHelp changes the code by adding in other bits as configured. With baking cookies or generating WebHelp, what you end up with is different than what you started with.

So, after the cookies have baked and cooled appropriately (WebHelp has been generated and is sitting in the Output folder) the cookies (WebHelp files) need to be moved from the cookie sheet (WebHelp output folder) to the display case or the cookie jar. Think of the display case or cookie jar as being like the Web Server you post the files to. The process of Publishing is copying the files from the output folder to the Web Server.

Does that make more sense? Hope so.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! Adobe Certified RoboHelp HTML Training SorcererStone Blog RoboHelp eBooks

[Robo_Solar]

I guess publishing feature it is intended for sending generated content to a remote server.

With SVN, we use this feature to copy generated content to a local folder, within a SVN working copy, which can be later committed to a svn repository.

[Captiv8r]

Hello again

When you boil it down, really all the Publish function does is to copy files from one place to another. With WebHelp, yes you are typically wanting to copy the generated output from the output folder to the Web Server. But as you have seen, it doesn't have to be a Web Server. Really it can be most anywhere you have access and authority to use.

RoboHelp also includes a stand alone utility to accomplish what the Publish feature of the SSL dialg does. It's called the Smart Publishing Wizard and you should find it in the Toolbox. Earlier versions of RoboHelp HTML had a Toolbox tab on the bottom of the left panel. Adobe RoboHelp version 7 and 8 have a Toolbox Pod you may open via View > Pods > Toolbox.

Whereas the Publish feature of the SSL simply assumes the WebHelp output folder, the Smart Publishing Wizard allows you to choose both Source and Destination folders.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95! Adobe Certified RoboHelp HTML Training SorcererStone Blog RoboHelp eBooks

[dh2help]

The fix is really easy!!!!   When you click Generate on your SSL you save it to folder A, but when you get to the last screen titled WebHelp Publish - multipleSSL(when using WebHelp) you publish to folder B.  I have made many changes, Published to B and have committed the updates to SVN with no problem, yea!  For some reasons generating messes with SVN, but Publishing does not.

Steps for the Publish screen:

1. Open the appropriate SLL.
2. Complete the geratation screens as usual.
3. At the Publish screen click New.
4. Give it a name.
5. I select File System from the Connection Protocols to save it to my computer, you may have a different place that uses FTP or HTTP.
6. Then just navigate to the correct folder and click OK
7. Select any necessary Options.
8. Click Finish.
9. After the application generates click the Publish button instead of View Results or Done.

You can also right-click on your SSL and select Publish after you have set it up the first time, until then that option is not available.

The Publish screen lets you create multiple publish options and turn them off and on my clearing the check box.  To edit or delete a site just click on the configuration and select the appropriate button.

[Robo_Solar · Accepted solution]

Yes, to get the output versioned under SVN we use the Publish feature, mentioned by previous post.

However it appears that if you delete some files from the project, they are not removed from the Publish folder.

So the folder is going to retain old and unused files. It generally won't hurt, but it really may generate some confusion.

Does anyone knows a good method to avoid this?

[dh2help]

I tested the Check for deleted files option and it doesn't seem to do anything when I tested it.

[Peter Grainge]

It has always been the case that files have to be deleted manually from the publish location as there are valid reasons for putting files there that are not part of the project and you would not want those deleted.

The Check for Deleted Files is for a different purpose. If a file is part of the project, this option checks to ensure it has not been manually deleted. If it has, then it republishes the file. If you have Republish All ticked, I believe Check for Deleted Files is disabled on the basis it does not then need to make that check.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Robo_Solar]

In order to purge the Publish directory when it is under SVN version control we use the following precedure:

1) perform a svn delete of the publish directory

2) generate and publish with RoboHelp

3) perform a svn add of the publish directory and a svn commit

This has one big disadvantage: the size of your svn repository will increment each time (since history is preserved, and lots of file are re-added even if they haven't changed)

Alternatively, you can use "SVN-cleaner" (http://code.google.com/p/svn-cleaner/). It will allow to delete all old files mantaining the folder structure and the svn metadata info (.svn folders). Then you can publish, and perform an svn add+commit. Files that haven't changed are not added again to the repository.