Advice: Breaking one project into three

[ghillerson]

Hi,

I have a large project that includes 6 "books", all related to our primary product. We're now developing a 2nd product, the documentation for which will include 3 of those books, and a subset of the topics from the other books; some of those 'shared' topics will be moved into a different directory structure in the new product's documentation (simplifying the structure in the new but can't do so in the old).

I'm struggling with the correct approach to this. I've read about global linking, and I've decided to create 3 projects: one for all of the shared content, including topics, stylesheets, images, conditions, variables, skins, etc., and one for each product's unique topics, TOCs, and Targets.

What I thought I would do is:
1) Clone my current project into a new 'Common' project. Open that in Flare, and create a simplified structure in there, so that all links are properly updated. By simplified structure, I mean moving topics that are nested inside folders so that all topics within a book are at the top level, with the intent that I'll impose structure in the TOC, not in the directory structure.

2) Somehow branch that into two additional projects ('Prod1' and 'Prod2'), each of which has its unique files and links to the topics and other files in the Common project.

I'm unclear on how to handle step 2); specifically, if I clone the Common project into a Prod1 project and then replace the common files in Prod1 with links to those files in 'Common', it seems like all of the inter-topic links will get screwed.

I'm guessing that people wiser than me have devised working strategies for doing what I'm trying to do. I would appreciate any suggestions.

Thanks in advance,
Gary

[devjoe]

You may be better off using conditional formatting to exclude the content you don't want in the new project, and generate everything with two different targets in the same project.
You can do conditional formatting in the TOC also to deal with the two different structures for part of the TOC.

[ghillerson]

Definitely not the answer I was looking for

Unfortunately, that's not going to work here, for reasons I won't go into. I assume that global project linking must have a way to deal with this. Someone?

thanks anyway,
gary

[ajturnersurrey]

I have done what you are describing...

I have a Software project which feeds a project for our BASICS product line and one for our PRO product line. The Software project only produces one target (the generic software manual) but the BASICS and PRO projects have their own unique topics and each produce lots of targets, every one of which includes topics and pictures linked from the parent Software project, along with the same page layouts, stylesheets, condition tag sets etc...

To break a single project up like that I would start by applying tags to items, whilst you can see links to targets because everything is in one project. In my case I have some items tagged ShareWithBASICS and some items tagged ShareWithPRO.
(I have heard of people using their folder structure to identify the files which get shared, but that would be more difficult for me to manage).

Then copy the project to set up three identical projects initially. Then rename, in my case one is Software and the other two BASICS and PRO.
Then go to the BASICS/PRO child projects and set up an import to bring in from Software everything tagged ShareWithBASICS/PRO respectively. That sets up the linked files. The linked icon will appear on all of the files which will now be routinely updated from the link.

The next exercise is to remove the now unwanted files from these projects.
I can recommend working with Analyzer on each project (if you have it) to spot unused/unlinked files and delete them, or use File List to group together files which were only tagged ShareWithPRO in the BASICS Project and vice versa to delete these on mass. (In my case I always move the unwanted files to a temporary folder, until I have rebuilt all my targets and confirmed I haven't accidentally deleted something I shouldn't, then finally press delete on those files!)

I would tagging is important, because later, when I am updating topics in Software I can easily see whether a given change should drive me to rebuild PRO or BASICS targets too. This is a level of information that you otherwise lose by breaking projects up in this way.

[ajturnersurrey]

I should add, don't worry about your links. Global project linking is really a way of copying files around to different projects so that a common source is used. So topic A in a child project may be linked (it is only updated in the parent project), but any cross-reference to it from topic B will still point to topic A in the child project, in the same way it always did.

[ghillerson]

Thanks, AJ. I now understand how to do this.