Community
Participate
Working Groups
How to reproduce: 1- Create a review 2- In Clear Case, check out a file, make some modification 3- Create a new review item from the checked-out file 4- Un-checked-out the file 5- Open the review item created just before in an editor --> The "OUTLINE " view does not display anything --> If you try to navigate from the file in the editor, it doesn't open the link file, For example, select "String" and press F3 key
I do not see the problem with the outline view. However, there is a navigatability problem for Java file if the file is a target file that is not in the workspace (i.e. the target is an external file). What seems to happens is that the CompilationUnit in JDT for the target file is not recognized properly and the one for the base file is used instead. The first time a resolve for a Java element is done on a newly open compare editor target file, the correct CompilationUnit seems to be returned from the CompilationUnitDocumentProvider#getWorkingCopy, stored in the fFakeCUMapForMissingInfo HashMap. However this "correct" CompilationUnit is changed by the SelectionConverter in performForkedCodeResolve that uses the CompilationUnit#reconcile method to replace it with incorrect contents. From then onwards, every Java element resolve is made using the incorrect CompilationUnit. The only place in the R4E code where we could have something wrong is in the R4EFileRevisionEditorInput, we I cannot see what could cause this. Egit uses similar code for their history compare editor but it works fine for them. I also verified that the problem is not dependent on the JRE used (1.5 and 1.6 equally fail).
Update: It seems that the CompilationUnit class in JDT sees itself out of synch with the buffered contents. This is shown in method JavaModelManager#getElementsOutOfSynchWithBuffers which contains our R4EFileRevisionEditorInput CompilationUnit contents as out of synch. It should not be. I'm starting to wonder whether this is not linked to bug 359617 and the changes that were made to the CommandUtils#getTargetFileData and getBaseFileData methods
The problem was that we were returning the same path for all file versions in ReviewsRFSProxy#getIStorage#getFullPath, so the internal buffers used by the JDT CompilationUnit to store the Java contents were overlapping. The solution is to append the localId (SHA) to the file path so different file versions are stored in different buffers that are not overlapping. Similar code is used in Egit CommitBlobStorage#getFullPath. Now we can ahieve full navigatability for both workspace and external base and target files!
Using latest code on Oct 25th, Navigation does not work from compare editor or single editor, nor from base file or target file. Ouline info. is populated though. To reproduce imported jgit git files, create a commit review item (a bit old, to find files out of sync with work space) open the files in compare editor try navigation (did not work for most cases)
After some investigation, it seems that navigation does not work when the classes we are trying to resolve are in the same project as the file we use. Take note that this might not be an R4E issue, as using the Egit history files gives the same results
I use LINUX 64b with C files and there is no outline view
After some extensive investigation it seems that R4E behaves exactly like any other plugin regarding outline view content, navigatability vs workspace and external files From the compare editor, outline view content is not available. Navigatability works all the time with files synchronized with workspace and external files, if the resolve target is part of the workspace. From the JDT editor, Outline view content is available for both workspace and external files, but the R4E menu is not available in the outline view for external files (see bug375149). Navigatability works all the time with files synchronized with workspace and external files, if the resolve target is part of the workspace. From the CDT editor, Outline view content is available for workspace files only. Navigatability works all the time with files synchronized with workspace and external files, if the resolve target is part of the workspace.
