This content has been marked as final. Show 12 replies
Need more info.
From your post it sounds like you have the project source files stored on a network drive. Are you pulling the files from a network drive and working on your local drive? Or were you working the project across the network?
If everything is in source control, can you check all of them out onto your local drive?
Hello "Linux Rules" And friends:
Yes, basically, we have a single Robohelp Project managed under Microsoft Visual SourceSafe on a network server. Several users download a "local" copy of the Project and make textual updates to over 750 Pages/topics.
The problem is occurring that I can see in MS Visual SourceSafe that the "fpj" folder for one of the subsets of files (Ex: All documents in the 2000-2007 Files folder) are present in SourceSafe, but aren't displaying.
I learned from other forums that the "FPJ" file manages sharing and how the files display in a shared project.
In my case, all of a sudden, the FPJ file is blank, hence, the files are in the project (specifically, that folder) aren't showing up.
the documents are there, but they won't show up in my locally downloaded folder since the fpj file is blank (my HUNCH)
Any advice as how to fix ti?
Should I just compare it to another folder and attempt to manually create the FPJ file?
Hello FTB -
Can we assume you have looked at other FPJ files and understand the structure? Are you comfortable writing that type of code (it isn't difficult)?
If so, download everything from your source safe, build the missing FPJ file(s) from memory/scratch and see what happens. Don't forget to re-check all project settings, primary layout and run the various reports from the Tools menu.
Have a good and safe weekend.
We see this problem quite frequently with RoboSource Control in our X5 projects. Can you roll your fpj files back to a previous version?
The FPJ-files contain a list of folders and topic files residing in their respective folder. A folder or topic would 'vanish' when you remove it from within RoboHelp Office.
What does you source control system's history tell you about those FPJs? Somehow they seem to be modified, is there perhaps someone on your team who runs with a corrupt version of the project? This you would see when examining a FPJs history.
@Gravenstein: yes, you can roll back a FPJ to a previous version, but any folders/topic files added in the meantime would have to be re-imported or re-defined.
Thanks Dirk and Gravestein- and friends!
Yes, It may be that one of my coworkers had a corrupt fpj file which was checked back in and then we lost all changes.
I was trying to recreate the FPJ file, but it looks to be tougher than it looks.
I assume spacing and filenames has to be exact, as when I try to resubmit /check in my manually created fpj file, it doesn't read it.
The issue is that the files are all still in the project, but they won't display due to the FPJ file being empty.
I suspect this may be attributed to one of the issues mentioned earlier. I think my only options are:
a) recreate the FPJ file carefully, based on other folder FPJ files
b) reimport the files and save a backup copy of every FPJ file for a "moment in time" every few weeks
Either way, I guess it means rework I suppose.
Now, does anyone know if there is a LIMIT as to the number of files or their respective sizes that can be imported to Robohelp?
We've lost several FPJ files, and I suspect its due to the fact that our PROJECT is too big...we have over 500 files, all filled with JPEGS and graphics. The project is over 50 MB!
Please advise, as this will help me piece together the mystery here!
I would advise you to thrash the existing database and set the whole thing up as new.
For this make a compilation of the most complete version around, de-compile the CHM in a shiny, new folder and copy the original project's HHP-file into this folder as well.
Now you can open the project via the HHP-file and re-import topics from the original location as necessary.
Finally add this reconstructed project to an all-new database.
This procedure gives you a copy of your existing project without any legacy problems.
For a project this size, expect the re-construction (setting up the new project and importing the files) to take maybe one hour.
Oh, one more thing: when your new project and database are up and running, label the status of the FPJ-files in the database! Pay close attention to those files in the database to detect if anything goes down the drain again.
Thanks Everyone, I'm going to use a couple of your tricks, but Dirk, you're simply awesome!
I didn't know we could decompile projects!
I found the help topic on the forum, and will try that. Yes, this will mean I will have to recreate several key folders, but hey, as long as it works.
So is the concensus that I should back up my FPJ files frequently? How is it best backed up? Just a simple copy and paste to a separate location? Are there any other files I should back up as well?
We currently us MS Visual Source Safe, so I suppose I could automate this if necessary.
Nevertheless, I guess this was inevitable, knowing the sheer amount of problems I've already had with RH X5.
Thanks again - Much appreciated!
In more than three years working with X5, we've never had any problem with the FPJ-files, so I still think their vanishing is rather a symptom than the problem.
Have you looked at a FPJ's history in Source Safe? In your place I would try to find out what happened when in the first place. All my tips are just general hints on how to save a project when it starts behaving strangely.
One thought just occurred to me: are you sure that only the files needed are under source control? CPD, LDB, PSS and (probably, but I don't know because it pertains to Visual Source Safe) SCC must not be put under source control.
Oops, I've got a meeting now!
Yes, i'm pretty new to the Robohelp X5 Game, so with little documentation, we had put the ENTIRE project under Source Control.
Do you think that could be the problem?
It's just that 5 developers work on the same project under MS Visual SourceSafe, and I'm not sure if constant changes from these developers cause a problem, or is it deeper.
We've had folders vanish several times in our project, and do suspect the FPJ files, as they seem to blank out whenever this occurs. It's a tedious process to reupload 100-200 files AGAIN and AGAIN, and I do fear future development and add-ons to this project may not be possible.
Any insight into this would be great, as in the long run, my predecessor would appreciate it!
I work with a team of 4 writers with source control (VSS). As Dirk said, we don't include the CPD, LDB, PSS or SCC in source control.
Occasionally we find a file or two missing, but not too often.
We don't generally work on the same project at the same time however, so I can't comment on how that would work.
One thing that seems to help for us is deleting the CPD file locally before opening the project, if someone else has worked on it. For example: I work on project A for a release. Then Jim works on a patch release for project A, so he deletes the CPD as he wasn't the last user to work on it.
This can take a while to re-verify if the project is large and has a lot of history in source safe...
From most things I've read, the CPD file shouldn't affect the project, but when we don't do this, some files go missing, or new files aren't picked up when someone else edits the project.
It might also help to manually "Get" the project each time you work on it too.
Hope this is useful.
trying to make it a bit clearer: if you add a project to source control using the 'Add to Source Control' command from within RoboHelp Office, the files mentioned are not put under source control. They all contain information relevant to your local working copy of the project.
PSS contains information on the local paths used to generate the output. It includes absolute paths.
LDB is the lock for the CPD-file.
CPD is an Access-like database file in which RoboHelp Office tracks changes on the project. As these database files are wont, they usually become corrupt after some time. This leads to unexpected behavior of RH: changes you have performes vanish after you re-open the project and stuff like that. While each local version of the project has a CPD-file, they are specific to these local version and cannot be replaced by other version, e.g. from the source control database.
So when RH behaves strangely, close the project, delete the CPD, re-open the project and take a nice walk, as rebuilding the file takes quite some time. But take care that the CPD is never ever under source control!
I don't know what peculiarities are introduced when using VSS instead of RSC, so please take everything with a grain of salt.
@Amber: what you describe is indeed one possible symptom of a corrupt CPD, but I can't imagine how this occurs because of other users working on the project.