.apj file is incorrectly marked as checked out

[Jonontrack1]

All authors have checked in all of their topics, yet Robosource shows one file (in this case rhcolor.apj) as 'Checked Out'. When the author attemps to Uncheck the file, Robosource returns the error message "rhcolor.apj is not checked out"

Anyone got any ideas?

[Gravenstein]

Hi Jonontrack1 -

Welcome! Try this: Log into RoboSource Control Explorer and verify that the file is indeed checked out. If it is, do an uncheckout from there. Depending on how the permissions are set up, you might need RSC admin privileges to do this. (Probably not, though.)

If it's NOT checked out, then the problem is likely local to that author's pc.

G

[Jonontrack1]

Thanks for the response G

Looks like the problem was local to the pc ? - would be very interesting to know what conditions would cause it, as we are setting up best practices to avoid these types of situations viz local copy and Robosource are out of sinc, but get latest doesn't fix it.

In the end, the only way we could rectify the problem was to delete the local copy of the project, and then use 'get latest' from robosource.

Regards

Jonontrack1

[Gravenstein]

Sounds like you applied the right solution by starting over on that pc.

Now I haven't run into this lately, but I'm guessing it's still true...One condition that has caused odd behavior like this at the pc level is when the author moves or copies the source files on the pc. This can confuse RoboSource Control and make synchronizing files a real problem. For example, say an author checks out a file from Location A. Some time later, the author goes to a different copy of the same project in Location B and opens that project. From that vantage point, the author sees that old file checked out to himself/herself, but RSC won't allow any further action on that file. (I think what *RSC* sees is two different authors, because of the two different locations. Or something like that.) The waters get further muddied if the author has deleted the Location A version of the project, because the trail gets lost.

Whenever possible, I like the writers to place their copies of the RSC project in exactly the same location on their pc. For example, everybody accessing the ABC project has the project located on their pc in C:\MyHelpSource\ABC.

G.

[Jonontrack1]

Just an update on the solution, I got it wrong. The deletion of the local project files, and get latest on that specific pc didn't work. The file was still shown as checked out.

What did work, was for all authors to log out, at which time we re-started the service on the robosource server. When everyone logged in again the faulty pc was OK. From this, it seems that perhaps the server has some sort of cache for each author which is reset when the service is restarted??

If it happens again we will go through this process.

regards

[Gravenstein]

Just out of curiosity, how long had it been since the service was restarted (or the server rebooted)?

G

[Jonontrack1]

Approx 1 month

[Gravenstein]

Depending on the amount of source control activity you have going on, you might want to reboot that server -- or at least restart the RSC services -- more often than that. I don't recall offhand what we've got our server set at, but it's at least once a week. On the occasions where it's been as long as a month between reboots, our RSC3 starts having problems. (Back in X5, with RSC2, if we didn't have a *nightly* reboot, we'd often run into trouble!)

G

[Jonontrack1]

Thanks for your feedback - we will include your suggestions in our 'general housekeeping' procedures. It seems prudent to adopt a 'belts and braces' approach to Robohelp and Robosource application management.

regards