1 person found this helpful
This workflow might help to minimise the issue in a source control environment - it's no solution, but a partial work around for us.
When multiple authors access a project in our organisation, it's normally sequentially (that is, not working on the project at the same time).
When an author starts work, they check who last worked on the project. If it wasn't themselves, they delete the cpd file before opening the project. During this process, sometimes we get a message saying some files need to be writable, even though we aren't checking out anything at this stage. Saying No at this point prevents the fpj file being blanked out. (For us, this file isn't the root.fpj, but one in a sub-folder and I haven't been able to work out what causes this folder to misbehave.)
I've always found the cpd causes problems when multiple users are adding or removing files, so we make it a habit to delete the cpd for any project that might have multiple authors.
The blanking of the fpj file only occurs for one project as far as I'm aware.
hope this helps.
So, you're saying that writers do the following?
Check prior RSC checkout, and if another writer, do:
- Delete the .cpd file from their local machine
- Open the project and say no to the "Get" request
This actually reinforces our decision (reached after I posted this inquiry) to enable the following option:
Tools > Options > General > Clear project cache(.cpd file) before opening any project
Might help...can't hurt.
I think the "Get" bit is okay. (I actually have that option off, myself, but some of my collegues have it on.)
Where we have problems is with a message something like "The file xxx needs to be writable" and we say No to making it writable. This is before we check anything out of source control and the message doesn't occur for all files in the project; typically only a couple.
This problem jumped up and bit us on a different project that had not been worked on for several months.
I've submitted another bug report, and I also mentioned this time that comparing different versions of the file is extremely difficult because RH grabs entire chunks of code and places it elsewhere in the topic. The result is that the code shows as deleted in one version, and then shows as deleted in a different location in the other version.
Not only does RH8 move blocks of text, but sometimes turns it ALL CAPS!