Community
Participate
Working Groups
I have projects in my workspace that are sync'd with both SVN and CVS. When I need to do an "Update" from the repositories I have to manually select all project by type (CVS or SVN) and then do an update for each kind. This is painful. How could this be done better? One way would be to be able have a Navigator view filter that only displays projects in CVS or only displays projects in SVN. This would allow me to choose a filter and do a select all/Update. Anoher way would be Select all project and do an Update. This is not possible today. You could imagine that if an action requires no UI, then the same action from different providers could be merged into one in the menu.
+1 for this. It seems actions like update, commit and create patch should be in public Team API where different team providers can participate.
Of the two proposed solutions, I prefer the first suggestion. It should be easy to create and maintain a working set for each repository provider type that is associated with projects in the workspace. As for the second suggestion, the problem is that it is beyond the mandate of the Team component in Eclipse. The mandate of the Team component is to help repository providers integrate into Eclipse. Of course, usability is also a goal but only if it does not make integration harder for repository providers. Having a single update command that all repository providers implement would complicate integration with Eclipse for repository providers and is not something we would consider without buy-in from all repository providers that integrate with Eclipse.
Michael, can't you implement this common update feature trough "adaptable" interface? So, those providers who are willing to implement this feature would be acting nicely with integration tools, such as Mylar, Buckminster and some others.
As I said, the current mandate of the Team component is to support repository intergation into Eclipse. It is not to define an API for accessing repository funtionality. The definition of a repository API would require the participation of a significant number of repository vendors. There is such an effort in JSR 147 (WVCM) but it doesn't seem to be making much headway. I think that the work that is happening in Mylar and Buckminster is a good start towards defining the kind of repository funtionality that tools need. As these tools grow in popularity, it is possible that more and more repository providers will integrate with them. If there is commonality between the Buckminster and Mylar requirements, it is possible that they could decide on a single API that meets both there needs. These are the necessary first steps towards defining a repository API that is implementable by repository providers and usable by client tools. However, I think it is far to early in the process to consider adding API to the Eclipse Platform to support this.
Michael, I believe that provisional API is better then no API. This stuff has been requested number of times and we can't just wait when JSR-147 wil be ready...
Eugene, while I agree that have a Team API would be cool, you should keep in mind that the percentage of users who have projects from multiple repositories in their workspaces is quite small. Also keep in mind that the Team component is about the layer that fits between repository provider and Eclipse. What you are talking about is a layer between tooling and repository providers. There is no reason why this layer needs to be in the platform. Both Mylar and Buckminster have defined there own API and the repostory bindings for them. There is nothing to stop Mylar and Buckminster from working together to define an API that meets both their needs. If it is a good API, others may start using it and extend it as well. Depending on the shape of the API, it may even be possible to implement a generic update API. This could all be done as plugins outside of the Platform and, if it succeeded, may one day be considered for inclusion there. Until such an effort has the involvement of a large number of repository vendors and tooling clients, I think putting it in the Eclipse Platform would be a mistake.
Michael, you have very reasonable point of view. However I still believe it would speedup adoption of such tooling API by non CVS/SVN team providers if this API would live at the platform... and as a result everybody would be abe to enjoy benefits of such integration much earlier.
We didn't have time to address this in 3.3.
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.
