Problem Importing Topics Between Projects

[notv4me]

This has fast become my new favorite place!

Ok, here's the scoop:

We had RoboHelp x5 and just moved to RoboHelp 8 a month or so ago. Shortly after the conversion, we copied all of our topics from our original project into a new project for a new product we're rolling out later this year.  The products are similar, but the names of screens and windows are different, so when a new topic is created, slightly different versions need to be created for each. I thought instead of manually changing each topic I could create the topic in one project, then open the other project, import it, and change the template to match the color scheme for the other product and be done with it.

But somehow my doing this caused almost all of the nearly 3000 topics to become "not controlled" in RoboSource Control, affecting myself and 5 other developers. What about the import would cause this to happen and is there a way to prevent this?

I was hoping that for each change we could just change one, import to the other and call it a day instead of having to manually do it twice. Is there a secret way of doing this that doesn't break the system and irritate my co-workers?

Thanks,

WD

[Captiv8r]

Hi WD

I'm going to move this thread to the Source Control forum category where you might hopefully see some suggestions offered.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[notv4me]

Thanks!

Warren

[Guest]

Just to clarify the situation a bit, is this what happened?

1. You created project A in RH X5.

2. You converted project A to RH 8.

3. You put project A into RSC (before or after conversion?).

4. You created a new project B in RH 8 and imported all the existing topics from project A OR

    You made a copy of project A and renamed it project B.
    (Which one of these methods did you use?)

5. You put project B into RSC.

6. You have successfully been editing topics in project B and checking them back in to RSC.

7. When you need a new screen topic, you add a topic to project A (and therefore to project A in RSC).

8. You import the new topic to project B. The newly imported topic is not in RSC ("Add to source control") and all the other topics in project B are now out of RSC ("Add to source control").

9. The topics that lost their source control are still visible in project B's Project or Topics pod.

I don't have a solution (barely an inkling), but I am wondering if there is some connection between these projects in RSC that shouldn't be there.

An additional question - are you importing these topics into the root directory or into folders within project B? A couple of people have reported some RSC instability when changes are made to the content at the root level.

[MergeThis]

You'll need to branch the A for B, and then use Reconcile Changes between folders and topics, as needed. Obviously, some of the source files should not be reconciled (.xpj, *.ssl, pblsvrs.sss, for example), but topics and images will.

See http://forums.adobe.com/thread/466244?tstart=60 for some instructions on branching.

Good luck,

Leon

[notv4me]

I read that thread, but am more confused now than I was before!

Warren-

[notv4me]

Here are the steps that we took:

1. Project A (call-guides) is in RH8 and under RSC control.

2. Got latest versions, closed RH8 and then copied my local Project A (call-guides) folder to another location. Name that folder Project B (udhelp).

3. Removed all files in the Project B (udhelp) folder from being under RSC control. (Changed all Read Only attributes, deleted pblsvrss.sss, deleted call-guides.cpd, deleted call-guides.pss, deleted the <miscproperties> section in call-guides.xpj) 4. Opened the uncontrolled project B in RH8.

5. Used RH8 to change the project name from A (call-guides) to B (udhelp).

6. Compiled Project B (udhelp), saved all and closed.

7. Opened Project B (udhelp), added all to RSC control.

In regards to your additional question, yes I was importing them into the root so they would be in the same place as all of the rest of the topics.

Warren- 414-221-3210

Senior Communications Support Specialist

[Gravenstein]

Is there any reason why you can't just select the uncontrolled topics and add them to source control?

G

[notv4me]

With six developers, it would be too difficult to coordinate adding topics back to source control every time this happened, especially since RoboHelp does it without warning. The real issue is why importing topics from one project to another causes files to become Not Controlled.

Warren- 221-3210

Senior Communications Support Specialist

[Amebr]

If the topics look like they are in source control at the time they are imported, and are only out of control after another developer has worked on the project, I would suspect the cpd file on each developer's pc trying to open the project as it last knew about it.

We use VSS for source control and we delete our cpd if someone else has worked on a project since last time. For example:

1. Person 1 creates a couple of new files for the project.

2. Person 1 checks who worked on the project last. As no-one else had worked on the project, they just open the project and do some more edits.

3. Person 2 checks who worked on the project last. As it was Person 1, they delete the cpd file before opening the project.

etc.

The rebuild of the cpd file can take a bit of time for some projects, but seems to minimise the number of missing topics (or re-added, if the previous person deleted some) in our projects.

Another option might be that some administrative files, such as the fpj aren't being checked out correctly. You could try checking out the entire project before importing new files and see if that helps.

Amebr

[MergeThis]

The .cpd file is a machine-specific file, and should not ever be in source control (any SC product), as also the .hhp, .pss, and .ldb files.

Good luck,

Leon

[Captiv8r]

Heya Leon

Sorry, but you have confused me a bit with your statement that the .CPD is machine specific.

It's always been my understanding this was a *Project* specific file. So can you expound?

Thanks... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[MergeThis]

If:

• User A's Local Path for a project is C:\MyProjects\AdminProject
• User B's Local Path for the same project is C:\MyGoodProjects\AdminProject

...and both users delete their .cpd file and open the .xpj file, will their .cpd files be identical?

Doubt it...

Suffice to say that RSC 3.1 does not add the aforementioned files as part of the database creation for a project.

Good luck,

Leon

[Captiv8r]

Hi Leon

I know you have researched and you know and share what files should and should not be part of source control, that part is cool.

What is curious to me though is that if the CPD were machine specific, why do things just work if you copy a project from one folder to another on a different PC. I would think if that were the case, the project would refuse to open an operate on the second PC or even in a different folder on the same PC.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7 or 8 within the day - $24.95! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[MergeThis]

Rick, "why do things just work if you copy a project from one folder to another on a different PC?" Because in a normal (non-SC) environment, RH will simply use whatever .cpd file exists, and adopt it as its own on that local machine. And since it's a binary file, I have no idea what it does internally to achieve that. (I haven't been able to read binary since that lobotomy.)

However, we're dealing with Source Control (the title of this forum).

Good luck,

Leon

[Gravenstein]

To clarify, the cpd file is project-specific AND machine-specific. At least it is if the cpd is generated locally.

Leon's right. RH will indeed adopt another cpd file as its own. We've used this to our advantage with large projects, where rebuild a cpd file can take literally hours. There does appear to be at least one thing that will trigger RH to do a cpd update cycle, though. If RH sees that some entry in the pss file doesn't match (not sure offhand which one(s) ), then RH starts grinding through some sort of cpd update thing.

This works with RSC projects, too, as long as they live in the same specified path.

G

[Amebr]

We don't source control the cpd, pss or ldb. However, I believe RH incorrectly classes the hhp file as an 'output' file. As far as I'm aware, there is nothing machine specific in it and can be useful in case something goes pear-shaped with the xpj.

Without the cpd in source control, we encounter issues with files added on one computer not being recognised on another, and the only way to get RH to recognise the additions is to delete the cpd and force RH to reanalyse the project. Although to be fair, we haven't not deleted the cpd file in a while - maybe a recent version has fixed a problem since the last time we tried it.

[Peter Grainge]

RH8 has an option to always create a new CPD on opening a project, sounds like that would work for you.

---

See www.grainge.org for RoboHelp and Authoring tips