Update to RoboHelp Dropping all Files/Content

[Guest]

Hi,

My colleague has now encountered the same problem as I described here:

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

Here is the content of her report:

"A similar problem that happened earlier to Derek is now happening to me. I was generating the WebHelp output for our merged project (the merged project is a container for all the sub-projects and we generate them all one by one to create the online help output). When I opened the last sub-project on the list (we have 15 sub-projects at the moment), I suddenly had two instances of the RoboHelp project running – one looked like the normal project and the other one had no content, it was just a template project with some default files. And then RoboHelp crashed. All I could see was an error message saying that RH has encountered a problem and is closing.

When I opened the project again, all the project files were missing. See the attachment for an example of the empty project.

All the correct project files were still in the project folder in SVN but now there were also all these additional files which were not there before. When I did an SVN commit on the project folder, I got a long list of files that were added and also a few of the real project files were marked as updated. See a  list of these files in the attached screenshots.

To solve this problem I had to do a fresh checkout of the Documentation folder in SVN. After the fresh checkout, the problem project opened normally with all the files in it and I was able to generate a Web Help output normally.

We are wondering if this could be a network issue (connection to SVN) rather than a problem with RoboHelp? RoboHelp works fine 99% of the time, and then suddenly, with a random project, this issue occurs. Could RoboHelp lose the connection to the files in SVN for some reason and this is why it crashes and loses all the project files?

We are using RoboHelp 10 with SVN (TortoiseSVN 1.7.7, Build 22907 - 64 Bit) and the operating system is Windows 7."

Addendum: I switched machines + new RH install, in an effort to rule out a HW issue. However it occurred again on the new machine.

/Derek

[Guest]

Hi Peter,

Our support team are not convinced this issue is related to SVN at all.

Perhaps you might move it to a different forum as the Source Control forum seems to be a lonely place.

Regards

Derek

[Willam_van_Weelden]

Hi,

So removing the project from local disc and getting the latest version from the server, doesn’t solve it? Is it possible to get the version of the help before the crash and open that?

Perhaps it could be that a CPD file was corrupted somewhere. I use TFS, but whenever the server goes down or the connection is lost, RoboHelp just starts giving errors. It doesn’t try to check in extra files. Somehow a RoboHelp project got confused and started adding those files.

Greet,

Willam

[Guest]

Hi William,

We have almost ruled out a network problem.

We work with our files locally and only connect with the SVN server when we commit or update our projects.

This problem does not occur during an SVN operation. It only occurs when working locally.

In answer to you questions:

Yes, we can remove the project from our local disk and get the latest files from the SVN server - this fixes it, as all the files are then restored locally.

Yes, it is possible to get a version before the crash - locally - by doing a revert, but the files are still missing. The problem still exists - empty project (but files still exist locally- just not showing up in project). The only way to fix it is to bring the project down from SVN, that is, doing a fresh SVN checkout.

This issue has now affected two members of the team.

We don't think this is a source control issue and would like if this issue was moved out of the Source Control forum if that is possible, where it might get more visibility.

Regards

Derek

[Peter Grainge]

As requested the thread has been moved to RoboHelp HTML. Sorry I missed your earlier request.

I am not a source control user but  I cannot see how a project that has crashed can check files in. A crashed project cannot do anything. Maybe you will need to contact Tech Support on this one.

What if you check everything out and remove the source control link?

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Guest]

Thanks Peter.

What if you check everything out and remove the source control link?

Yes, good point. That is going to be our next test when we get time, as we suspect it’s not related to source control or the network.

The issue has not occurred since.

[Guest]

Hi,

Our tech support are adamant that this problem is not connected to SVN: because we work on local copies and only use SVN to update or commit changes. I think they are correct. This problem manifested itself again today. It occurs only when opening a project - no interaction across the network with SVN is taking place. Two instances of the application (the same project) seem to open concurrently. One contains the expected content, the other is an empty project as described earlier. Closing the corrupted or the correct one, first or second, makes no difference. The project directory now contains only the corrupted project.

This is happennng to more than one user.

Regards

Derek

[Captiv8r]

Hi there

Question here.

How exactly are you opening the project?

That may sound silly, but please read on.

One way is to simply locate the XPJ and double-click it. The other way is to have RoboHelp open, then click File > Open or to click the most recent project among the list of them on the RoboHelp Starter page.

Cheers... Rick

[Guest]

Not a silly question. We tend to double-click the xpj file.

[Captiv8r]

Thanks for the response.

I think It's worth trying the other way. Open RoboHelp, then from inside RoboHelp, open the project. Personally, I've never ever worked by double-clicking the XPJ file. Doing that causes Windows to launch into a series of events. Opening RoboHelp, then opening the project. And my thought is that perhaps some event you are unaware of is being triggered from working this way.

So please try working the other way for a few days and see if the problem disappears.

Cheers... Rick

[Guest]

Ok Rick, thanks. I could try that.  Although it will be slower, because we have to manage multiple product releases and it will mean navigating to the correct release directory from the File -> Open menu. Usually I have the release directory open and just double click the required xpj file.

One thing to note (if I didn't earlier), this problem seems to occur when I am working with several projects in quick succession, that is, I am opening and closing projects quickly, doing checks, and using the xpj file to do so. I could open and close six or seven projects very quickly until one finally throws a wobbler. This could tie in with, as you say, the xpj triggering a series of Windows events which throws RH into a tailspin.

/Derek 

[Jeff_Coatsworth]

To really rule out source control, I’d be tempted to copy one of the sample projects into your local c:\projects\[project_name]\ folder, open it in RH, give it a new name, edit it some and save it. Then zip it up and stick it somewhere on your network. Delete it from your local machine and then bring it back down from the network, unzip it and reopen it in RH – everything cool? Issue’s in your source control; pooched? – it’s your environment.

[Guest]

Hi Jeff,

We'll give that a try as soon as time allows.

Thanks

/Derek