This content has been marked as final. Show 10 replies
Hi there William
If you are using the Publish function of RoboHelp, you are only publishing the files that actually changed. Not sure if that helps or not. Probably doesn't, but thought I'd mention it.
I suppose you could become creative and publish to a folder on your hard drive, then possibly sort by date so the newest files float to the top where you could easily identify them.
Just thinking out loud here... Rick
Rick, thanks for the suggestion.
I had thought of doing a similar approach, but I was hoping to find a solution that would yield a pre-packaged file, not one that forces me to manually select the proper files, which to be honest is error-prone even for the best of us.
Since the Publish approach already has identified the subset, producing a zippable update package would be extremely simple for the Dev team. You all hear that... ;-)
Hi again William
I don't suppose AIR output is an option here? With that output, you are able to place a reference point on the web. If things change, the user is prompted to install the new AIR.
I don't believe it's a differential. I think it's a whole new install, but it might offer an option for simplifying things.
Rick, while that might be an option for some, it is not for us, due to configuration management and being a Web-based app and help. This would be useful to anyone in a controlled environment.
I'm not sure you understood Rick's reply, since you answered "but I was hoping to find a solution that would yield a pre-packaged file, not one that forces me to manually select the proper files, which to be honest is error-prone even for the best of us."
The Publish function is different from the Generate process. That is:
1. When you Generate WebHelp output to a location on your local machine, RH clears the folder and populates it with all new output.
2. When you Publish WebHelp output to any number of locations on any number of servers, RH adds or overwrites only the changed files, unless you check the "Republish all" option.
The server URLs are added to the Servers box in the WebHelp Publish dialog (the fourth dialog in the generation wizard).
I understood clearly and use Publish regularly. It does not do what I need and that is to create a Changed File Version of the project. I can get that from the directory I Publish to with Search and a time sort. However, since I cannot publish to the servers directly, must check in my changes, and want to save the space when distributing by only using the changed files, what I asked for is what I wanted.
I hope that is clearer.
Could you not publish to a local folder named Build001 and next time publish to a local folder named Build002 and then use something like Beyond Compare to ascertain the differences,
I think you could also use it to delete the unchanged files.
You would need another copy of Build002 for the next iteration.
How do you propose to clean out deleted files from the final locations?
While I could do what you suggest, RoboHelp itself should supply this since it already does something similar itself, but without the additional packaging step. Rather than add another external process to the workflow that must be approved, documented and supported, I need RoboHelp to do this for me.
As to removing deleted files, that is not an issue on these periodic updates. When we do a new full build everything get replaced. I am looking for an way to simplify interim monthly edits, addtions and fixes.
I have not seen too many posts from people wanting to work this way. Not to say there is anything wrong in it, just not common and as with any software company, popular gets the vote when assessing what goes in and what doesn't.
Suggest you make Adobe aware of what you need.