Community
Participate
Working Groups
Version: 3.2.0 Build id: I20051102-1600 All of the ChangeSetProvider classes are marked internal. While these classes are internal, we can not add the change set feature to Subclipse. I have implemented a simple change set provider for Subclipse that does not yet supported checked in changesets. I could attach it here if you wanted to see another implementation. Could ChangeSetProvider be considered for includion in the 3.2 API?
I agree with Brock, if this API is internal, many 3rd party plugins, including Subclipse won't consider implementing the feature. Also, many vendors don't even consider to support integration Eclipse builds, primarily because of dependencies on derived tools (like Rational), so if this feature won't make into next public release it will delay adoption. Another thing I'd like to mention that some plugins can use their own metadata to create commit sets, e.g. Mylar is using unformation about changes that happens within specific task context. So, it is important that commit set API is used by all team providers.
Our original intention was to make this API in 3.1 but we didn't have the manpower to complete it. Now, in 3.2, our main focus is logical model integration (bug 37723). This new support will have an impact on the synchronization API. Because of this, I think it would be unwise for the change set code to be made API until the logical model support API is finalized. Given the tight schedule the platform is on, it is not likely that we will have time to address this in 3.2.
Is this on the table for 3.3? It looks like both Subclipse and Subversive are relying on it now, and others will doubtlessly need it. I'm voting for this because Mylar users benefit from team providers having change set support (http://wiki.eclipse.org/index.php/Mylar_Integrator_Reference#Integrating_Team_Providers).
There are actually two orthogonal issues here. This request is to make the outgoing change set support that is used by CVS API so that other repositories that do not have the first class notion of an outgoing change set (like subversion) can reuse the implementation. I have been contemplating whether or not to put this in 3.3 but we have a lot on our plates so I don't know if we can find the cycles to implement and maintain the API. I'll tag this as 3.3 just so it stays on our radar but I can't make any guarantees. The other issue that is being piggy backed on this one is the desire to have a third party change set API so that clients like Mylar can create repository change sets. It is mentioned in comment 1 that it is important that all team providers implement this so that third party clients can have this capability. The problem is that there are repository providers out there that have a first class notion of an outgoing change set already so they would never want to use the Eclipse API (i.e.ActiveChangeSet class and friends). That is why it is important to keep these two issues separate. It is good for Mylar to want to define an API that allows them to interact with repository change sets. However, I think it is a mistake to use the ActiveChangeSet directly for this. In essence you will be excluding all repositories that have a first class notion of outgoing change sets from interating fully with Mylar. I don't know what the Mylar architecture is like but I hope that it does not (or will not in the future) depend on ActiveChangeSets directly. A better approach would be to define an independant API that meets the needs of Mylar and then build a bridge between that and ActiveChangeSets so that any repository can integrate with Mylar.
We do not have the manpower to address this issue in 3.3.
We'll consider the priority of this when doing Mylyn 3.0 planning and if it is high enough try to contribute a solution since we are inherently coupled to the change set internals.
We made some progress on this for Mylyn 3.0 and managed to de-couple the Mylyn Team API from CVS internals (bug remove bug 191793). Our single remaining API leak in Mylyn 3.0 is ActiveChangeSetManager, which is still required by our Team API. This means that clients using our the Mylyn Team API will need to couple to Platform Team internals. In other words, we still don't have a proper API here and fail to insulate clients from the ActiveChangeSetManager internals. We considered making a non typesafe facade that would ensure binary compatibility, but that layer of indirection seemed to be more of a disservice to integrators due to the extra layer of indirection and lack of an API Tooling warning. We almost succeeded at providing a proper facade for ActiveChangeSetManager and friends by hooking up our own teamContentProvider that allowed extensions to specify their own change set models to be specified (e.g. our CVS extension specified org.eclipse.team.cvs.core.changeSetModel). This didn't work because the Team API is, probably quite sensibly, not designed to support this kind of overriding/shadowing. For the next Mylyn release cycle we will look into what it would take to create our own API as per comment#4. The fear we have is that we would copy and re-implement way too much of the current internal change set management which already does everything we need, but perhaps there is more elegant solution possible.
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.
