Community
Participate
Working Groups
This task will keep track of the progress related to the implementation of the core connector for projects associated to the subclipse team provider. This will need a cq as subclipse is not an eclipse project.
Wayne, what are the steps that we need to take in terms of IP approval? We would want to build against Subclipse and distribute a feature that requires Subclipse but not redistribute Subclipse itself. I think that Buckminster does something similar with their Subclipse support.
We'll need a WORKSWITH dependency on Subclipse on the basis that "The Eclipse software does not require the third party software to be present. If the third party software happens to be present, the Eclipse software may call or invoke it." [1] I'll follow up with Buckminster; they'll need to do the same thing. [1] http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
Thanks Wayne. I'll initiate the PMC approval process. Alvaro, can you please list the features that are required as direct dependencies for the connector?
(In reply to comment #3) > Thanks Wayne. I'll initiate the PMC approval process. Alvaro, can you please > list the features that are required as direct dependencies for the connector? Here is the list of features needed, using the 1.6.x Release: Provider tigris.org, http://subclipse.trigris.org/ org.tigris.subversion.subclipse_1.6.18 org.tigris.subversion.clientadapter.feature_1.6.12 org.tigris.subversion.clientadapter.javahl.feature_1.6.17 org.tigris.subversion.clientadapter.svnkit.feature_1.6.15 org.tigris.subversion.subclipse.graph.feature_1.0.9 Thanks to both.
To clarify, do you expect that org.tigris.subversion.clientadapter.javahl.feature, org.tigris.subversion.clientadapter.svnkit.feature and org.tigris.subversion.subclipse.graph.feature will be necessarily needed as dependencies (to build and install) the Subclipse connector? Particularly SVNKit is likely to cause problems due to the license.
(In reply to comment #5) > To clarify, do you expect that > org.tigris.subversion.clientadapter.javahl.feature, > org.tigris.subversion.clientadapter.svnkit.feature and > org.tigris.subversion.subclipse.graph.feature will be necessarily needed as > dependencies (to build and install) the Subclipse connector? Particularly > SVNKit is likely to cause problems due to the license. We have a lot more flexibility with regard to license in a WORKSWITH. In this case, I believe that we can expect that the sort of user who is installing this feature will have already installed Subversive, right? It's the user/adopter's responsibility to accept the license in this context. Note that the workswith declaration will grant you the ability to build against the software, but it cannot be stored in the project VCS or otherwise distributed from an eclipse.org property. I assume, also, that the Eclipse software will not be attempting to install Subclipse, but rather will leverage it if it is already there. Please let me know if this is an invalid assumption.
(In reply to comment #5) > To clarify, do you expect that > org.tigris.subversion.clientadapter.javahl.feature, > org.tigris.subversion.clientadapter.svnkit.feature and > org.tigris.subversion.subclipse.graph.feature will be necessarily needed as > dependencies (to build and install) the Subclipse connector? Particularly SVNKit > is likely to cause problems due to the license. Looking deeper into this, there is only one feature needed to build and install org.tigris.subversion.subclipse_1.6.18 Some of the other features will be needed for proper operation but that will need to be selected by the user e.g. javahl or svnkit.
(In reply to comment #6) > (In reply to comment #5) > > To clarify, do you expect that > > org.tigris.subversion.clientadapter.javahl.feature, > > org.tigris.subversion.clientadapter.svnkit.feature and > > org.tigris.subversion.subclipse.graph.feature will be necessarily needed as > > dependencies (to build and install) the Subclipse connector? Particularly > > SVNKit is likely to cause problems due to the license. > > We have a lot more flexibility with regard to license in a WORKSWITH. In this > case, I believe that we can expect that the sort of user who is installing this > feature will have already installed Subversive, right? It's the user/adopter's > responsibility to accept the license in this context. > The ideal situation would be to have separate bundle connectors, the call to the corresponding bundle would be derived based on the team provider associated to a specific project in the work space. if the project is attached to subversive, the subversive connector will be searched and it will be activated (if already installed), similarly for a project attached to a subclipse team provider, the subclipse connector will be searched and will be activated (if already installed). The above does not require the installation of subversive or subclipse in any way. It WORKSWITH either one as long as they are attached to a specific project in the workspace. > Note that the workswith declaration will grant you the ability to build against > the software, but it cannot be stored in the project VCS or otherwise > distributed from an eclipse.org property. > This is fine as the user is the one installing subversive of subclipse. > I assume, also, that the Eclipse software will not be attempting to install > Subclipse, but rather will leverage it if it is already there. Please let me > know if this is an invalid assumption. This is also fine, the application relies on the team provider associated to a project in the work space, the installation of the team providers is a user decision/action.
I have posted to the PMC mailing list: http://dev.eclipse.org/mhonarc/lists/mylyn-pmc/msg00072.html.
I have submitted a CQ to track the works-with dependency in the IP log: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5289.
The coding will start now, the first draft is estimated to be available in about 3-4 weeks, when it will be attached to the CQ
No need to attach the code to the CQ. The CQ is mostly for documentation. Please commit files directly to CVS as you create them.
Ok, that's better. I will do that
Work has just started, the initial skeleton of the plug-in has been created
The svn -log -v command comes back with an Action i.e. 'A' -> Add, 'D' -> Delete, 'M' -> Modified, 'R' -> Replaced It seems 'R' may come in two different formats, although I have not found an actual detailed description for it. e.g. a) R /trunk/folderX/file.ext (from /trunk/folderY/file.ext:123) b) R /folderX/file.ext The first form (a), is actually quite practical for our purpose since we can obtain the base element in the same line. (for modifications we need to resolve the base by finding the previous commit for each of the files in the target commit). the second form (b), does not indicate the base, as per lack of information. I am assuming this is the case where the actual path did not change, however the new version is taken from another one not usually.
Created attachment 199631 [details] patch funtionality contributed by Stefan Reiterer, needs to be committed
Created attachment 199632 [details] mylyn/context/zip
To: Stefan Reiterer, The patch added to this bug is functionality taken from your code at: git://github.com/sreiterer/mylyn-reviews-scm-integration.git This functionality is really needed to complete the first draft of the Subclipse core connector using the Mylyn versions interface As you are a committer in the Mylyn Versions project, you can commit this code directly. Questions and comments are very welcome
Hi, I will have a look at the patch and commit it as soon as possible.
I see the patch has been successfully comitted Thanks Stefan. I have also marked the patch for iplog.
Great! You can remove the IPlog flag. It's only meaningful for patches attached by non-committers. Since Stefan made the commit there is no need to track anything in the IP log. Is there anything left do here?
(In reply to comment #21) > Great! You can remove the IPlog flag. It's only meaningful for patches attached > by non-committers. Since Stefan made the commit there is no need to track > anything in the IP log. You are right, I have removed the IPlog flag > > Is there anything left do here? There are performance issues but they shall be addressed by separate issues. So I am marking it as Resolved.
