> > > > > > wdyt ? > > I find some of your language confusing... by deprecate, do you mean > "remove altogether"? >
I mean "remove from core but include an automated conversion to alt plugin" > > If there is a licence problem that prevents the SVN plugin from being > shipped as part of Jenkins, then the answer is to not ship it as part of > Jenkins - if you need SVN, you'd just have to install it separately, > like any other plugin. > backward compatibility is the rule here. removing svn without a migration plan means many build farms to be broken the license issue only applies to recent 1.7 svnkit, not the one used for existing subversion plugin > > What was the reason for not using the JavaHL bindings again? (The Java > bindings provided with Subversion itself). > same : backward compatibility -> javaHL requires host to have a svn client > > Anyway, I think the 'right' way to do this would be the way Subclipse > works - offer a choice between JavaHL and SVNKit. > > That is to say, that the main Subversion plugin could ship as part > Jenkins and would use JavaHL, with "subversion-SVNKit" being an > extra/optional plugin (to avoid the licencing issues). There should be > no need to change the interface (i.e. how it's configured), except > adding the option to choose/prefer one backend over another... > > Eddy > > -- > Edward Cullen > Software Engineer > n.able Technology Services > mailto:[email protected] > > Assigned to Data Protection & De-duplication: D2D - HP Storage > ----------------------------------------------------------------------- > Hewlett-Packard, Long Down Avenue, Stoke Gifford, Bristol, BS34 8QZ, > United Kingdom. > > The contents of this message and any attachments to it are confidential > and may be legally privileged. If you have received this message in > error you should delete it from your system immediately and advise the > sender. > To any recipient of this message within HP, unless otherwise stated, you > should consider this message and attachments as 'HP CONFIDENTIAL' > >
