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