How nested can merged files be?

[tripwire45]

I think this should probably work but I thought I'd mine the experience of those of you who've been working with merged projects longer than I have (which should include just about everyone). I have just been informed (like about 5 minutes ago). that two separate projects involving two separate products need to be merged. The thing is, both of these separate projects have numerous subprojects involved that have already been merged (call the Project A and Project B).

Project A is the older project and was written and constructed by my predecessor. It is vast involving tens of books and hundreds of topics including several separate subprojects. The subprojects are nested at different directory levels of Project A and this project is the backbone of the primary product's documentation.

Project B is a project I developed from scratch for a new product. I developed a master project and four subprojects. The subprojects are all merged at the top level of the directory (I like to keep things simple) and works just fine as an overall stand-alone project.

Now I'm told that Project B must be able to operate as a stand-alone set of help files but also be merged into Project A as a subproject. I figure I can copy all of the Project B master project and subproject folders into the directory containing Project A and merge it from there. That way, I can have my cake and eat it too, so to speak.

I just want to confirm that this is a viable plan before I give it a whirl and have it tank on me.

I (finally) have a documentation review meeting scheduled for Monday with the "powers-that-be" to avoid future surprises like this and to nail down management's plans and expectations for documentation, so I can actually plan my help file structure ahead of time and before actually creating the initial structure. :sigh:

Thanks for the responses.

[RoboColum_n_]

quote:

---

Originally posted by: tripwire45
I (finally) have a documentation review meeting scheduled for Monday with the "powers-that-be" to avoid future surprises like this and to nail down management's plans and expectations for documentation, so I can actually plan my help file structure ahead of time and before actually creating the initial structure. :sigh:

---

Ahh! The Holy Grail. Good luck.

Seriously, I've never had nested projects with a lot of book levels purely because as a user I'd soon get fed up with drilling down and go elsewhere. That said, I appreciate that it may be necessary here. If it is, you can easily test to see if there is a limit. I've never come across one or remember anyone posting about one here.

To add to the comments above, you are aware that if Project B needs to be a nested and standalone project that you will end up with multiple copies of the CHMs that make up that project. It's not a problem provides everything is updated after a compile. You could handle this but duplicating your HTML Help single source layout to output to a different location and use the Batch Generate function to compile both Microsoft HTML Help outputs at the same time.

[tripwire45]

I don't think I'm going to have much of a choice, but I can certainly mention the technical aspects of doing this in RoboHelp during the documentation review meeting on Monday. I may not be offered much of a choice, though so pursuing the "holy grail" my be a forced option (though frankly, the only "holy grail" I'm really fond of is the "Monty Python" version). 😉

[Peter Grainge]

I believe I did set up such an experiment with webhelp. is that what we are talking about here? Helps to know.

I have a feeling that the index and search did not work properly, if indeed it worked at all.

What you need to do is abandon your real projects and set up a test scenario, replicating the structure you need. In each project have just a few words of text unique to that project. That way you know what you are really looking at and what the search is and is not finding.

Before you start, book yourself into a rest home while you are still capable of doing that.

[tripwire45]

quote:

---

Originally posted by: Peter GraingeBefore you start, book yourself into a rest home while you are still capable of doing that.

---

LOL. It may come to that. I guess I could spend today and tomorrow creating a relatively complex structure of help projects and see what flies and what doesn't. We are talking about CHM files rather than WebHelp so it probably makes a difference. If I create this thing and it doesn't work, I'll have a good excuse to tell "the-powers-that-be" that it can't be done...at least in RoboHelp.

[tripwire45]

Ok, I can make it work, but it's kind of "cloogie". I used on test project I used to test basic merging (one master and three subprojects) then created a separate project with one master, four subprojects and one subsubproject merged into a subproject.

I got "Test2" to work but in order to get a nested subsubproject to show up in the master's TOC, I had to copy the subsubproject's CHM into the master's !SSL! folder manually, then create the usual merge project links in the TOC.

To get Test2 to merge into Test1 took that basic concept and expanded on it. I first had to copy the entire directory structure containing all of the Test2 master and subproject files into the folder containing all of the Test1 subproject folders. Then I had to manually copy all of the CHM files from Test2 directly into the the master Test1's !SSL! folder, then add just the Test2 master as a merged project link in the Test! master's TOC (yeah, it's complicated to try and explain).

Bottom line is when you finally compile the main master, everything appears in the TOC and you get a sufficiently involved set of books, subbooks and subsubbooks mapping to the right pattern of nesting. I haven't done anything beyond the basics so there's no indexes, browse sequences and so on, but I could add all that and test again. If this keeps up, I'll end up writing my own RoboHTML help files.