Community
Participate
Working Groups
CVS Repository view should leverage the Logical Model. This would allow a consistent user experience.
This will require as to replace currently used TreeViewer with CommonViewer (from Common Navigator framework).
If my memory serves me correctly, i would require a lot more than that. The current logical model support uses IResource as the common currency but there are no IResource available in the Repositories view. An API based on a lower level file system, like EFS, would be required.
Thanks for your comment Mike. I remember that long time ago you mentioned something about a rough implementation of a CVS repository browser based on EFS for CVS. Is the result of your research available anywhere? Could you point me to it? The only thing I've found so far is bug 114756 for "read/write CVS implementation for the EFS" (marked as WONTFIX) and org.eclipse.team.internal.ccvs.core.filesystem package in org.eclipse.team.cvs.core. The package seems to contain an EFS implementation which used internally by the CVS plug-in to work with a file system in a CVS repository.
The CVS EFS implementation you found was the extent of our research in that area. We didn't do any work at the UI level.
Created attachment 149446 [details] Prototype v01 Patch that illustrates the idea of using the CVS EFS implementation to browse CVS repositories. The trick here is that when browsing HEAD we create a project for each top level folder/module. This takes place only if the remote folder contains ".project" (is a project) and a local project with the same name doesn't exist. It's a prototype, browsing by branch, version or date not supported, sorry. Moreover, these newly created projects pollute the workspace, mixing with local projects. Repo view's tree is replaced with common viewer and newly created projects resides in CVS file system. It's a prototype so if you by any chance decide to apply it and run you will get plenty of NPEs reported by Java Tooling and Builder. I suggest you turn off "auto build" before playing with the patch. Even though the patch is not very useful it points to some serious limitations/threats which need to be considered before going any further: 1. Only top-level modules/folder will take advantage of logical model support. If repository contains a project which is not top-level (e.g. /moduleName/plugins/yourProjec) it will be treated as folder not project. To fix this we will need to allow nesting of projects (see bug 245412). 2. Workspace must contain unique project names. If a project exists in workspace, a project (representing a module/remote folder to be used by CVS EFS) with the same name cannot be created. The name could be created basing on project's URI or the project could be added to some kind of "virtual" workspace tree. 3. Hitting remote file system each time is time consuming. A deferred content/label provider which wouldn't block the UI is required. Current CVS Repo view make use of such providers. 4. Adding some kind of caching to the EFS implementation would be great. 5. "CVS projects" take part in the building process, an option to mark them as team private could prevent it. 6. Each model provider needs to bind its content extension to the new CVS Repositories view.
Created attachment 149447 [details] mylyn/context/zip
I had a little chat with Szymon and we came out with 3 possible approaches for this issue: 1. The first approach is illustrated by "Prototype v01" patch. The idea is quite simple. We use CVS EFS implementation to create and manage Resources in workspace tree. To avoid interfering with builders, notifiers and to prevent displaying these resources in workspace tree we could use filters or team private flags to mark them. Model providers should see no difference between local projects and those located in repository so displaying logical models should be straigforward (but remember about comment 5, bullet 1.) 2. The second idea focuses mainly on skipping the Resources layer and making model providers consume EFS model interfaces like IFileStore. This way we could use current CVS EFS implementation and pass it directly to model providers without need to create any imitational resources and pollute the workspace. 3. The last one is a modification of 1., but instead of creating Resources in the workspace tree we could provide a virtual workspace tree, made up specially for remote resources. This would be a lightweight representation of workspace, still operating on IResources but without all the fancy stuff it normally has (like deltas, builders and so on).
Regarding 2., if we decide to skip Resources in the implementation it's possible that model providers won't be able to get all the information needed from IFileStores and IFileInfos. EFS is a low level API and it may not contain all the data required by a model provider.
Created attachment 151198 [details] Prototype#2 v01 Here's another quick and dirty patch that illustrates a different approach. This one has been inspired by Szymon's idea to map Remote Resources to Resources directly. The patch does not use CVS implementation of EFS at all, but still tries to translate remote resources to resources, which can be consumed by model providers. Each remote resource is wrapped by an object (called RProject, RFolder, RFile) implementing IResource interface. Moreover, each repo has its own RWorkspaceRoot and RWorkspace. The code is ugly, browsing a repo blocks the UI but at least it gives the idea. Again, the changes starts with moving to Common Navigator, but this combined with the extra layer for translating remote resources to resources makes us able to use org.eclipse.ui.navigator.resourceContent content extension and gives a visual effect similar to the one in Navigator. I know this is not full Logical Models support, but I think it can be considered as a step in the right direction. Other context extension may be provided and supported later.
I'm not sure if I emphasized it enough in the last comment, it appears that no matter which way we go our first step should be replacing currently used TreeViewer with CommonViewer.
Given the fact that the fix for this issue is still at 'investigation' stage and considering the complexity of the work that still need to be done, I'm removing the target milestone to better match the reality. Please let me know if this would an important feature to you, but be aware that there is practically no chance this will be fixed in 3.6.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
