Community
Participate
Working Groups
There are cases when projects are using different version control systems, e.g. for historical reasons or while migrating. When dealing with those one would have to create multiple synchronizations and it is difficult navigate trough changes when they are broken across multiple synchronizations.
One hurdle to getting this going is figuring out how to provide a common triggering mechanism. Currently, all repo providers contribute their own actions to the Team menu and Sync is driven by that (or by creating a new synchronization in the sync view). One possibility would be to have some way of adding more than one repository type when creating a new synchronization. Needs further investigation.
Hmm. Why do you mark it resolved then? You could at least use "remind later" resolution...
To clarify: while this could be an interesting feature, the problem is that as a platform, Eclipse can only "speak" for CVS. We can't provide an implentation of a generic sync action for all other repo providers that integrate with Eclipse, and unless we can get a broad consensus from most other repo providers, we wouldn't feel comfortable forcing this type of API on them.
Hmm. I would expect that platform should provide enough plugability to 3rd party providers to fit nicely into the developers activities... It is been pointed out before, but current Team API is designed based on CVS and has number of shortcomings that make it difficult for other providers to do certain tasks or have to reimplement same functionality over again. Besides, there is need from other tools (like Mylar) to be able to interact with Team providers and execute certain tasks (for instance, commit, create and apply patch) and none of this stuff has been made a standard API.
There are two things that are at odds here. What you are saying is that you work with multiple repositories and would like a unified view of those repositories. What repository providers want is the ability to provide a repository specific UI so that they can surface the feature that make their tooling stand apart from other repository tooling. We tried to have a unfied Synchronize view in Eclipse 1.0 and it was a failure because it provided the lowest common denominator. What we did in 2.0 is provide a set of low level integration points so that repository providers could surface their UI as they saw fit. Both the repository providers and the users were much happier with this architecture. Since 2.0, we have provided a CVS workflow that we, as Eclipse developers, like. Other users have indicated that they like it as well so we've made some of the pieces of this architecture API so that other repository providers could benefit from it if they desired. However, they are not required to do so and can provide their own workflows if they prefer. So, with that in mind, it is OK if we define optional Team API that others can choose to use or not. What we don't want to do is force repository providers to implement Team API in order to integrate into the Platform without their involvement in the genesis of that API. As you say, we, the Eclipse Team/CVS Team have not done a good job at defining generally useful API (i.e. it has been too CVS specific). Therefore, from your own argument it would be a mistake for us to define the API for a generic sync view. The API would only succeed if a good cross section of repository vendors were involved in its design. JSR 147 (mentioned in bug 37705) is such an effort.
Michael, JSR 147 is probably the way to go for a long term, but now it would make sense to at least handle common providers. There is already synchronization model supported by sync view, so why can't it allow aggreagtion of different providers? At least for some most popular providers... Also, it doesn't look like JSR 147 API is a good fit for high level operations such as commit, cheate patch, etc that are typicaly bound to Eclipse workspace ot even to specific synchronization.
Integration into the Synchronize view can happen at many levels and the repository providers can provide customized actions in the toolbar, view menu and context menu. In essence, what your proposal would require is a single level of integration into the Synchronize view with a unified set of actions. That is not something we want to force on repository providers.
(In reply to comment #7) > Integration into the Synchronize view can happen at many levels and the > repository providers can provide customized actions in the toolbar, view menu > and context menu. In essence, what your proposal would require is a single > level of integration into the Synchronize view with a unified set of actions. > That is not something we want to force on repository providers. Provider-specific actions could go into node-specific popup menu in the same way as in package explorer or navigator views. Personally I find toolbar actions really confusing, especially with that jumpy-buggy behavior of the current view toolbars. It should be ok to restrict actions like commit, create patch, etc. to single provider, but still allow integration tools to use common API to invoke such actions. I believe we have a separate bug report for that already.
I can appreciate this tension between keeping the API think thereby giving more control to the providers. However, it can result in a problematic user experience for those that use more than one repository, and many developers are forced to check out the sources of the APIs that they depend on. Personally, I rely heavily on the Synchronize view always showing me the diff between my workspace and the rest of the world that I find it confusing to have no way of knowing that there are changes in a SVN or FTP synchronization when I've got my CVS synchronization up (most of the time). So I wonder if this can be finessed by the UI. For example, how about providing a mode, called All Synchronizations, in which the top-level nodes are the individual Synchronizations (or Change Sets containing synchronizations)? Each provider can still get it's own context menu, schedule, etc, but at least multiple synchronizations would be visible.
By the way, Michael, isn't Synchronize view already using common navigator framework? For some reason I thought that it does allow to have different actions depends on the model.
The Synchronize view is just a paged based view to which repository providers can plug in pages. We do provide a page implementaion to repository providers that makes use of the Common Navigator framework in order to allow the repository provider to delegate the rendering of the Synchronization state to the models involved. However, it is up to the repository provider to decide whether they want to use the page we provide or if they want to role their own page (or even provide their own view).
Michael, can you please clarify how exactly that page would work for CVS provider and some other one? I am not sure how can user select two different provider types to be shown on the same sync page. Unless CVS provider is also not using this feature... Thanks.
Eugene, I'm not sure what you are asking. Are you asking me to speculate on what this feature would require? Or are you asking about the current shape of the Synchronize view framework?
(In reply to comment #13) > Eugene, I'm not sure what you are asking. Are you asking me to speculate on > what this feature would require? Or are you asking about the current shape of > the Synchronize view framework? Michael, you said that: "We do provide a page implementaion to repository providers that makes use of the Common Navigator framework in order to allow the repository provider to delegate the rendering of the Synchronization state to the models involved. However, it is up to the repository provider to decide whether they want to use the page we provide or if they want to role their own page (or even provide their own view)." So, I am asking if CVS provider does using sync page provided by team plugin? If so, how other plugins could add their synchronizations to that page in order to see their changes on the same page with CVS? I am confused, because it is not obvious from the Synchronization wizard UI.
Team provides a bunch of interfaces and abstract superclasses the repositories can implement. They are describe here in the ISV doc: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/team_model_repo.htm CVS makes use of the classes provided by Team to create a CVS specific Synchronize view. The framework is not structured in such a way to allow other repository providers to put their Synchronization results in the same page as CVS. It requires them to have their own page. If I was to speculate on a good starting point for supporting a page that shows results from multiple repositories, I would say that it would require an IMergeContext that delegated to the appropriate repositories IMergeContext. The problem is that you would need a command/action that knew how to build the merge contents for all the repositories involved. Also, this is only a starting point and there would be many more details that would need to be worked out (e.g. how would you surface the commit operation in the sync view).
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 339031 has been marked as a duplicate of this bug. ***
*** Bug 358354 has been marked as a duplicate of this bug. ***
Reopening the bug.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
