Community
Participate
Working Groups
Currently Eclipse is using proprietory views for CVS Repositories and CVS Resoource History. It takes too much screen real estate to have its own views for each type of source version control (SVC). Two most popular SVC's for open- source projects CVS and Subversion (see Subclipse project at http://subclipse.tigris.org/) has to use separate views. Please generalize team API, so 3rd party SVC providers will be able to plug into common views for repository exploring and resource history.
Would you like something like the Synchronize View which allows multiple synchronizations into the same view? I prefer this to generalizing the CVS views, because every version control system has it's own UI requirements and trying to define a common ground is useless. Also, history and repository browsing are two of the easiest views to write, so there's not much gain. We don't have any plans to work on this item in the near future. The workaround is to stack the views together.
Repositories probably most used one. It allows to browse and compare files and old revisions without checking out project locally. It would be nice to have generalized view for all repository types (they all hierarchical after all), however within particular repository we should have different actions enabled (providers should contribute to pop-up menu). Speaking about resource history view, providers can contribute entire content of this view as well as menus and toolbars. View should resolve repository type for attached repository and delegate to correct provider. Another similar view is annotations. If it is necessary, provider can add its own view (like cvs editors, pending svn operations and svn properties). It is good from a user experience to have a common place to get info about resource history, even if its content may look slightly different depends on the repository type. It will simplify navigation and should allow to have a common keystroke to switch into such panel and may allow to simplify provider development. Synchronize view is a totally separate story an I was going to fill another bug report for it. It should definetley allow to miz different SVC providers.
As a developer on the subclipse project i think this would be a good idea to have shared views. Jean-Michel is right about creating a single view for all providers being impossible. CVS and SVN are quite similar but that is most likely not the case for other providers. A page view would work for me (and match the existing sync view) A 'team management' perspective would make these views even more useful. It would remove the need to have both CVS and SVN perspectives. A good thing for developers who use more than one VCS. If we shared views it would be even better!
Brock, what is a page view? By the way, in my experience switching back and forth between Java, Team Synchronization and CVS Respository Exploring perspectives is not very convenient. It is a matter of personal preferences, but I usually add Synchronize and CVS Resource History and CVS Repository (in quick view mode) view into Java perspective because I usually have to work with multiple code branches and have to watch changes during refactoring. All my coworkers picked up this customization. Actually Synchronization view is the most handy one for team collaboration and Eclipse should expose it more verbosily for a newbies.
The synchronize view uses a page view. The entire contents of the sync view change when you select a provider (first button in toolbar). Each team provider implements their own view contents however they want and the user is given a generic way to switch between the views. The metaphore is supposed to resemble flipping pages in a book (you can only view one page at a time). Personally, I never use the CVS perspective. I was just saying that I would prefer to have ONE team perspective then one for each provider.
Brock, synchronize view actually show a subset of local files, so it is absolutely makes no sense to me to have different providers on a separate pages. However decorations and actions for shown elemenents, as well as the way how they retrieved and added into the resource tree is provider-specific , but it should be possible to somehow generalise it. However this is out of scope of this feature request.
Sorry, you are right about the sync view. There is one page implementation and providers pass it a configuration to do customisation. You can create your own pages though. The problem with implementing a generic Repository view or Resource history view is that there is very little in common across repository providers. The sync view has a well defined model (check out the SyncInfo class). This model does not change between providers. Changes are either incomming, outgoing or conflicting (in a three way case). The only thing that the resource history view has in common between CVS and SVN is the fact there is some sort of revision id and a description. The repository browser has almost nothing in common (other than the fact it is a tree like structure). I remember reading somewhere that Eclipse *DID* used to have generic team views at one stage but they were removed because they were considered too inflexible and not many (if any) providers implemented them. Can any of the Team guys comment on this?
Brock, I see your point. However form a user experience all repositories are trees. So, it will worth the effort. By the way, I wish it would be possible to search trough all registered repositories and/or have ability to use quick filter, like the one I've tried to explain at https://bugs.eclipse.org/bugs/show_bug.cgi?id=74795 If that ever happens it would be much more convenient to have a single tree for all repository types.
> I remember reading somewhere that Eclipse *DID* used to have generic team views > at one stage but they were removed because they were considered too inflexible > and not many (if any) providers implemented them. Can any of the Team guys > comment on this? You are correct. In Eclipse 1.0 (wow that seems like decades ago) we shipped with a generic UI (repo browser, history view...). The result what low-bar integration of all other SCM systems. Nobody was satisfied with this. Instead of trying to build a generic client views a better approach would be to solve the integration problems. - What would it take to allow different repositories to existing within the same view, even if the contents are semantically different. Note that this is something we've never done in Eclipse yet. For example, we have the Java Explorer and the Navigator, they aren't mized into the same view. - Improve Perspective sharing between Team Plug-ins
There could be two approaches: -- Completely replace content of view (good candidate is Resource History) -- Contribute child nodes into common tree-like structure (good candidates are Synchronization and Repositories views) In second case nodes should have provider-specific actions and only root elements of the tree model has to be generic and tree should be able to somehow display the rest of tree.
There is currently no plan to address this item.
Is there any chance this can be addressed for 3.2? At least History View could be made a common place holder for a plugin-specific panels.
We are adding a generic history view in 3.2. The first cut will be available in M4. See bug 120214 for the description of what we still need to do to make it on par with the exisiting CVS history view.
We're addressing this somewhat in 3.2
Fixed. The Generic Team history view is now in 3.2 M5. If anyone feel ther are still outstanding issues, please log separate enhancement requests.
