3 questions - Source control vs. sub-projects

Question

Hi -
I have 3 related questions:
1.) Seems like I remember a warning from a long time ago
(older versions) about having to check out the entire project -
because the user needs to access the .mpj/.xpj file. How does the
new RoboSource Control 6 handle checking out the project file?
2.) Also - Is it better to use sub-projects (merged projects)
or Source Control to support multiple users?
I believe one "con" to using merged projects is that you have
to manually deal with consolidating context IDs... Can anyone give
me some other pros and cons for each method?
3.) If I go with Source Control as the method for handling
multiple users - combining all of my topics into one project - I'm
concerned about the size of the project. I've encountered seriously
long compile times and corruption in past versions. Can anybody
provide real-world numbers for project size and compile time in
RoboHelp 6?
Thank you.

Answer 1

quote:
Originally posted by:
OE3-chick
Hi-
1.) Hmm.... so I think this means the the .xpj file would
still be accessed directly from a file share. So, if we worked
together and I opened the .xpj file to work on the project -
wouldn't it give you a warning that the file is already in use when
you go to open it and also work on the project? Can two people open
the same .xpj file now?
Oops, seemingly my fingers started typing the usual
answer before the brain achieved operating condition. The XPJ
contains no local stuff and can and should be committed to the
database. I was referring to CPD, PSS, and LDB.
quote:
Originally posted by:
OE3-chick
Regarding 2.) and 3.) Oop - I'm actually referring to authors
(users of the RoboHelp application). I was told that creating
seperate projects would allow multiple authors to use RoboHelp -
then they would be merged into a single project for the end
customer. So, my concern is about which method (
sub-projects/merged projects or Source Control) is better for
supporting multiple authors.
RoboSource Control is set up in such a way that multiple
authors can concurrently work at the same project. As soon as one
author manipulates a file from the project, this file is locked for
the other users. As long as different author ditribute the work on
the topics they can work without interferences. Exempt from this
optimistic description are the central files valif for the whole
project: HHC (table of contents), H and ALI (context sensitive
help), GLO (glossary), and BRS (browse sequences). the same is true
for the HHK (index), as long as you set up the project for using
this HHK-file.
So if you can teach your authors to concentrate on their
topics (and index entries) only in their work, and handle the other
stuff centrally, no one will ever notice that she is not the only
one working on the project. With up to five or six authors even the
conflicts are not so bad. Just ask the other who has locked, say,
the HHC to check it in and you can immediately work on the table of
contents yourself.
The other method using separate projects and merging the
stuff at run-time avoids these problems, but at a cost. Every
author can work on his (sub-) project to her heart's delight, but
getting the stuff together to form a seamless unit which looks to
the user like one help system only, takes some work. If users
should be able to open the help system via a context sensitive call
and the help should look a unified whole (all the help within one
window, index and TOC seamlessly merged, navigation through links
without errors), you'll have to fiddle around a bit.
quote:
Originally posted by:
OE3-chick
-- Is it better to use sub-projects (merged projects) or
Source Control to support multiple authors?
I believe one "con" to using merged projects is that you have
to manually deal with consolidating context IDs... Can anyone give
me some other pros and cons for each method?
If your programmers open the same help file for every help
call, you'll indeed have to manipulate the context IDs in a way
that RoboHelp does not support in its interface. Where a 'usual'
mapping reads:
CONTEXT_STRING=PATH/TO/MY_TOPIC.HTM
you'll have to write something like:
CONTEXT_STRING=MS-ITS::MAIN_HELP_FILE.CHM::/SPECIAL_HELP_FILE.CHM::/PATH/TO/MY_TOPIC.HTM
For each topic in one of the slave help files you'll have to
manually enter such a line into the MAP.ALI of the main project.
This works remarkably well, unless a user tries to open a
slave help by doubleclicking it in the Windows Exporer; he will get
an error message instead of a TOC.
quote:
Originally posted by:
OE3-chick
-- If I go with Source Control as the method for handling
multiple authorss - combining all of my topics into one project -
I'm concerned about the size of the project. I've encountered
seriously long compile times and corruption in past versions. Can
anybody provide real-world numbers for project size and compile
time in RoboHelp 6?
-Thank you.
Nope, as we are running X5 I can't answer this. But anyway, a
2,000 topic project takes some two minutes as far as compilation
goes; I wouldn't worry too much about this.
Regards
---Dirk Bock