Perforce plugin doesn't notice changes made in normal mode

[fabienbk]

Tried in eclipse 3.7 and 3.8

Step to reproduce:

• open a file (I tried in JDT, on a java source file, but it seems to happen with other editors)
• delete a line (dd)
• Save (Ctrl+S)
• Editor is now in read-only, and the line deletion is reverted.

If i switch to edit mode (i) and go back to normal mode before doing that, everything works great.

[keforbes]

I'm using Eclipse Juno (4.2) and I can't reproduce this defect. Is there anything keeping you on 3.7 and 3.8? Would you be willing to upgrade to 4.2 and see if you can still reproduce this defect? Or are there any steps other than what's described here that I should try?

[fabienbk]

Hi, thank you for your answer. Tried on a fresh 4.2 install and it worked, but then i installed my plugins and gotcha, found the culprit. It seems to be a weird interaction with the perforce plugin.

I suspect it has to do with the files being read-only by defaut in the workspace, and being set to writable as soon as you make a change (a single keystroke in the editor triggers that file permission flip).

When I perform a "dd", the perforce plugin (or maybe eclipse itself) does not register a change in the buffer, thus leaving the file as read-only. This causes eclipse to fail to save the file (when Ctrl+S is pressed) and reload the buffer from the disk.

I will try to find a workaround. This may include convincing my team to switch to git :)

[keforbes]

I'm sorry to say it sounds like you stumbled upon our oldest open defect. Here it is from our old defect tracking system:
http://sourceforge.net/apps/trac/vrapper/ticket/37

We don't integrate well with ClearCase or Perforce. I don't know what the problem is, but for some reason those tools just don't recognize file changes in normal mode. I use git for developing Vrapper and subversion at work, neither one have this issue. Good luck convincing your team! ;-)

[keforbes]

There may be a minor change in behavior for this defect. We've made a change such that Vrapper will not modify the contents of a read-only file. I don't use ClearCase or Perforce but I'm guessing this means if the file is locked and you attempt to perform a NormalMode change, Vrapper should complain and say the file is unmodifiable. Unfortunately, I believe this also means that Perforce still won't be able to realize you're making a change so it won't auto-checkout the file (since the change was prevented).

[sprigogin]

vwrapper needs to call org.eclipse.ui.texteditor.ITextEditorExtension2.validateEditorInputState() in response to user typing.

[keforbes]

@sprigogin, thanks for finding the method call that's needed to fix the defect; I certainly wouldn't have figured it out on my own.

I'm tempted to add a property like "enablePerforce" or something which would only call that method if the property was enabled since I don't think most users need it.

If the title of this defect is accurate and the problem is only with performing operations in NormalMode then I should be able to call that method after completing a NormalMode operation... Actually, that method is in the eclipse namespace which would put it in our eclipse project... that complicates things. It'd have to be quite the hack to invoke some method in our eclipse project after NormalMode completes something. You've given me the tools to fix this defect, now I just need to figure out how to use it.

[sprigogin]

The validateEditorInputState method is harmless in situations when the version control system works without it. The method is available for any editor derived from AbstractTextEditor. It's a good idea to be consistent with well established Eclipse code, for example http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/tree/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/javaeditor/CompilationUnitEditor.java.

[albertdev]

@sprigogin
I took your recommendation and integrated it in Vrapper. After testing it with Perforce, I can confirm that it works nicely if you call it before making any changes. Hopefully this means the ClearCase plugin works as well.

I might still move the code around a bit, but it shouldn't matter. Keforbes will likely make an unstable release sooner or later, after which you can test this fix.

[albertdev]

@keforbes
Just a side-note: it seems Trac is no longer reachable over at SourceForge. Did they delete it or is the URL changed?

[keforbes]

I've updated the unstable update site with a new build (0.47.20140816) which includes this fix. Hopefully this fixes most of our issues interacting with Perforce.

@albertdev, I think Trac has been completely deleted. I tried finding it when #482 was filed and I couldn't find it either. The URL used to be http://apps.sourceforge.net/trac/vrapper/ but that just redirects to the sourceforge page now.