3
Replies
3
3
Replies
LEGEND
,
Hi Tracy at Cheval
Unless you are using some sort of a Source control system, I don't believe a way exists other than to simply include some hidden comments in the topic code itself.
I assume you are referring to what you are seeing when viewing Tools > Reports > Project Status? If so, I think that may have been something that appeared eons ago and was never actually implemented in RoboHelp.
Cheers... Rick
Unless you are using some sort of a Source control system, I don't believe a way exists other than to simply include some hidden comments in the topic code itself.
I assume you are referring to what you are seeing when viewing Tools > Reports > Project Status? If so, I think that may have been something that appeared eons ago and was never actually implemented in RoboHelp.
Cheers... Rick
Hi again Tracy at Cheval
In your situation, I might suggest you would benefit from what I refer to as "poor man's version control". I'll outline below:
Using careful coordination, two or three help authors can easily achieve sharing a single RoboHelp project without resorting to any type of a third party Source Control system. The key to this approach is strict adherence to communication policies!
Source Control works like a combined traffic cop/librarian. It is an automated way to allow collaboration between two or more help authors. Here is a hypothetical situation. Three different help authors have a need to "share" authoring responsibilities. I'll refer to them as Mary, Bob and Mike. All three wish to update and maintain a single RoboHelp project. There are a few different ways that this can be done.
1. A Source Control system may be acquired and implemented. This could be cost prohibitive and require setup, configuration and ongoing maintenance that is undesired.
2. Mary, Bob and Mike may carefully communicate and essentially "share" a single project.
3. The project may be carefully split into three different projects and each of the authors becomes "captain of their own ship" so to speak. Each author is totally responsible for maintaining their own project.
In case number 1, a version control system is purchased and implemented. In this case, once it has been installed, each user is configured with a login name and password so that each is uniquely identified. Then one or more projects are added to the version control system. So let's say Mary checks out Topic1.htm to make an edit. Then Mike comes along and wants access to the same topic. The source control system says nope! Sorry, but Mary has it checked out. You can't make changes until she checks it back in! In this case, the source control system is preventing undesired changes from being made to the files. The traffic cop part stopped Mike. The librarian part kept track of the fact that Mary had the topic checked out.
In case number 2, careful communication is mandatory. So let's say Mike wants to make some changes. Here is what would need to happen:
1. Mike sends a message to advise Mary and Bob that he will be working on the project.
2. Mike copies the project from its central location to his hard drive.
3. Mike opens the project, makes the changes, generates or compiles, then saves the project.
4. Mike copies the modified version of the project from his hard drive back to the central location. This replaces the original with Mike's modified copy.
5. Mike then sends an "all clear" message to Mary and Bob, advising that either of them are now free to make any changes.
6. Perhaps at this point, Bob needs to make changes. In this case, the cycle repeats.
7. Bob sends a message to Mary and Mike advising he will be working on the project.
8. Bob copies the project from its central location to his hard drive.
9. Bob opens the project, makes the changes, generates or compiles, then saves the project.
10. Bob copies the modified version of the project from his hard drive back to the central location. This replaces Mike's modified copy with Bob's modified copy. At this point, because things were carefully applied, the central location now reflects modifications made by both Mike as well as Bob.
In case number 3, each author has his/her own project. Each is captian of his/her own ship! Essentially, each author has their own copy on their own hard drive. When changes are required, they simply open the project at any time they like, make changes and copile or generate as needed. In this case, one person is normally nominated as the "Master" or head person. This person's project contains special information that tells it to "look" for the other projects. This type of setup is known as either the "Parent/Child" or the "Master/Slave". The end result is that the person viewing your help system is actually viewing content provided by two or more separate help systems. But from their perspective, they see only one. So they are none the wiser.
Hopefully this helps... Rick
In your situation, I might suggest you would benefit from what I refer to as "poor man's version control". I'll outline below:
Using careful coordination, two or three help authors can easily achieve sharing a single RoboHelp project without resorting to any type of a third party Source Control system. The key to this approach is strict adherence to communication policies!
Source Control works like a combined traffic cop/librarian. It is an automated way to allow collaboration between two or more help authors. Here is a hypothetical situation. Three different help authors have a need to "share" authoring responsibilities. I'll refer to them as Mary, Bob and Mike. All three wish to update and maintain a single RoboHelp project. There are a few different ways that this can be done.
1. A Source Control system may be acquired and implemented. This could be cost prohibitive and require setup, configuration and ongoing maintenance that is undesired.
2. Mary, Bob and Mike may carefully communicate and essentially "share" a single project.
3. The project may be carefully split into three different projects and each of the authors becomes "captain of their own ship" so to speak. Each author is totally responsible for maintaining their own project.
In case number 1, a version control system is purchased and implemented. In this case, once it has been installed, each user is configured with a login name and password so that each is uniquely identified. Then one or more projects are added to the version control system. So let's say Mary checks out Topic1.htm to make an edit. Then Mike comes along and wants access to the same topic. The source control system says nope! Sorry, but Mary has it checked out. You can't make changes until she checks it back in! In this case, the source control system is preventing undesired changes from being made to the files. The traffic cop part stopped Mike. The librarian part kept track of the fact that Mary had the topic checked out.
In case number 2, careful communication is mandatory. So let's say Mike wants to make some changes. Here is what would need to happen:
1. Mike sends a message to advise Mary and Bob that he will be working on the project.
2. Mike copies the project from its central location to his hard drive.
3. Mike opens the project, makes the changes, generates or compiles, then saves the project.
4. Mike copies the modified version of the project from his hard drive back to the central location. This replaces the original with Mike's modified copy.
5. Mike then sends an "all clear" message to Mary and Bob, advising that either of them are now free to make any changes.
6. Perhaps at this point, Bob needs to make changes. In this case, the cycle repeats.
7. Bob sends a message to Mary and Mike advising he will be working on the project.
8. Bob copies the project from its central location to his hard drive.
9. Bob opens the project, makes the changes, generates or compiles, then saves the project.
10. Bob copies the modified version of the project from his hard drive back to the central location. This replaces Mike's modified copy with Bob's modified copy. At this point, because things were carefully applied, the central location now reflects modifications made by both Mike as well as Bob.
In case number 3, each author has his/her own project. Each is captian of his/her own ship! Essentially, each author has their own copy on their own hard drive. When changes are required, they simply open the project at any time they like, make changes and copile or generate as needed. In this case, one person is normally nominated as the "Master" or head person. This person's project contains special information that tells it to "look" for the other projects. This type of setup is known as either the "Parent/Child" or the "Master/Slave". The end result is that the person viewing your help system is actually viewing content provided by two or more separate help systems. But from their perspective, they see only one. So they are none the wiser.
Hopefully this helps... Rick
Resources
RoboHelp Documentation
Download Adobe RoboHelp
AdChoices