We noticed a very disturbing thing over the past couple of weeks in a couple of different Real Studio projects. Occasionally, we find that changes to code are not getting saved to disk despite what the IDE.
In both instances we had things in the code editor not get saved. The sequence was this:
- Open up code editor.
- Make changes (dirty flag goes on).
- Save (dirty flag goes off).
- Close project and then open it back up.
- Code changes are not saved.
There is a thread on the Real Studio NUG http://www.realsoftware.com/listarchives/realbasic-nug/2013-01/msg00188.html about this very issue and it appears that it might be a Mountain Lion issue. I wouldn’t necessarily disagree, EXCEPT that I was using Mountain Lion with Real Studio 2012 Release 1 with Mountain Lion and never noticed this issue. As someone working on projects all day long and using version control format I think I would have noticed it before R2.
Movie of our code loss:
For us the problem seems to occur when using the VCP project format in 2012 Release 2. That might be spurious data as we use VCP for practically everything and most of our projects are running in R2. This has happened in both desktop and Web Edition projects. Only 1 of these projects is being actively used by multiple people.
In one case I did a Save As over the existing VCP files and it appeared to make everything better and I’ve not seen the issue (in that project) since. I have not tried using Disk Utility to check permissions and other disk errors.
Is it a pure Mountain Lion issue, is it a Real Studio issue, or a combination thereof? Regardless, this is a very serious issue that the community needs to help figure out.
Have you seen this issue? Was it using the binary or VCP file format? Did you do anything to try and fix it? What and how did that fix work?
As seen in the comments section it appears that Norman from Real Software found the issue we were seeing and has it fixed. To recap: my bug only manifested itself in 2012 R2 version control format projects. You had to change source code in the event of a control on a web page and not change any property anywhere else on the page nor any code in any of the methods. It should be fairly rare to see this bug and we only found it because we hit that exact sequence.
Anyway, good news that it was found and fixed. I don’t think it’s the same bug as reported in the NUG though it might be distantly related. Only RS will be able to discover that.