Subversion plugin support for svn 1.7?

[Christoph Kutzinski]

Hi,

in case no one else has mentioned, there are currently a lot of complaints and a lively discussion in https://issues.jenkins-ci.org/browse/JENKINS-11381 why Jenkins still doesn't support svn 1.7 now that SVNKit 1.7 is released.

I would fix this myself, but I don't know what the Jenkins specific patches to SVNKit are and how to apply them to SVNKit 1.7

I'd like to take this opportunity to point out again that using a patched library is *NOT* a good idea and we should try to see how the Hudson guys solved it in this case.


cheers
Christoph

[Olivier Lamy-2]

What about having an other subversion plugin (not bundled with core
for license reason) called svn-1.7-plugin and which use svnkit 1.7 ?


2012/4/26 Christoph Kutzinski <[hidden email]>:

> Hi,
>
> in case no one else has mentioned, there are currently a lot of complaints and a lively discussion in https://issues.jenkins-ci.org/browse/JENKINS-11381 why Jenkins still doesn't support svn 1.7 now that SVNKit 1.7 is released.
>
> I would fix this myself, but I don't know what the Jenkins specific patches to SVNKit are and how to apply them to SVNKit 1.7
>
> I'd like to take this opportunity to point out again that using a patched library is *NOT* a good idea and we should try to see how the Hudson guys solved it in this case.
>
>
> cheers
> Christoph

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

[nicolas de loof-2]

Fully agree about patched libraries,

in the meantime, I've been inspired by the merge done by "centic" on JENKINS-11933 and I'm finalizing a merge for svnkit 1.7.4 to our fork

2012/4/26 Olivier Lamy <[hidden email]>

What about having an other subversion plugin (not bundled with core
for license reason) called svn-1.7-plugin and which use svnkit 1.7 ?


2012/4/26 Christoph Kutzinski <[hidden email]>:

> Hi,
>
> in case no one else has mentioned, there are currently a lot of complaints and a lively discussion in https://issues.jenkins-ci.org/browse/JENKINS-11381 why Jenkins still doesn't support svn 1.7 now that SVNKit 1.7 is released.
>
> I would fix this myself, but I don't know what the Jenkins specific patches to SVNKit are and how to apply them to SVNKit 1.7
>
> I'd like to take this opportunity to point out again that using a patched library is *NOT* a good idea and we should try to see how the Hudson guys solved it in this case.
>
>
> cheers
> Christoph

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

[nicolas de loof-2]

Olivier explained me the licensing issue with svnkit 1.7, with "TmateSoft License" is not compatible with Jenkins MIT as it requires all derivative to follow "complete source code for your application must be available and freely redistributable under reasonable conditions"

MIT let you do whatever you like with jenkins, this would require a license change, mostly GPL

This wouldn't apply if subversion is handled by another plugin, separated from jenkins core distribution. Would be also a good opportunity to get rid of those forks (during merge, I had to tweak the svnkit fork due to our for on trilead-ssh !)

Maybe it's time for us to deprecate the subversion plugin. Not sure how to handle backward compat, maybe core could keep a fake subversion plugin to automatically install the (new) svn-plugin on first usage, like OSX Lion does for java runtime

wdyt ?

2012/4/26 nicolas de loof <[hidden email]>

Fully agree about patched libraries,

in the meantime, I've been inspired by the merge done by "centic" on JENKINS-11933 and I'm finalizing a merge for svnkit 1.7.4 to our fork

2012/4/26 Olivier Lamy <[hidden email]>

What about having an other subversion plugin (not bundled with core
for license reason) called svn-1.7-plugin and which use svnkit 1.7 ?


2012/4/26 Christoph Kutzinski <[hidden email]>:

> Hi,
>
> in case no one else has mentioned, there are currently a lot of complaints and a lively discussion in https://issues.jenkins-ci.org/browse/JENKINS-11381 why Jenkins still doesn't support svn 1.7 now that SVNKit 1.7 is released.
>
> I would fix this myself, but I don't know what the Jenkins specific patches to SVNKit are and how to apply them to SVNKit 1.7
>
> I'd like to take this opportunity to point out again that using a patched library is *NOT* a good idea and we should try to see how the Hudson guys solved it in this case.
>
>
> cheers
> Christoph

--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

[Edward Cullen]

On 26/04/12 15:45, nicolas de loof wrote:

> Olivier explained me the licensing issue with svnkit 1.7, with
> "TmateSoft License" is not compatible with Jenkins MIT as it requires
> all derivative to follow "complete source code for your application must
> be available and freely redistributable under reasonable conditions"
>
> MIT let you do whatever you like with jenkins, this would require a
> license change, mostly GPL
>
> This wouldn't apply if subversion is handled by another plugin,
> separated from jenkins core distribution. Would be also a good
> opportunity to get rid of those forks (during merge, I had to tweak the
> svnkit fork due to our for on trilead-ssh !)
>
> Maybe it's time for us to deprecate the subversion plugin. Not sure how
> to handle backward compat, maybe core could keep a fake subversion
> plugin to automatically install the (new) svn-plugin on first usage,
> like OSX Lion does for java runtime
>
> wdyt ?

I find some of your language confusing... by deprecate, do you mean
"remove altogether"?

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.

What was the reason for not using the JavaHL bindings again? (The Java
bindings provided with Subversion itself).

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:[hidden email]

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'

[nicolas de loof-2]

>
> 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:[hidden email]

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'

[kohsuke Kawaguchi (CB)]

On 04/26/2012 07:09 AM, Christoph Kutzinski wrote:
> Hi,
>
> in case no one else has mentioned, there are currently a lot of
> complaints and a lively discussion in https://issues.jenkins-ci.org
> /browse/JENKINS-11381 why Jenkins still doesn't support svn 1.7 now
> that SVNKit 1.7 is released.

Indeed, I missed that. I just imported SVNKit 1.7.4, and updated
Subversion plugin accordingly. I've posted the RC of the new Subversion
plugin to JENKINS-11381, and deployed it to ci.jenkins-ci.org.

I'll wait for a few more days before releasing this as 1.40.


> I would fix this myself, but I don't know what the Jenkins specific
> patches to SVNKit are and how to apply them to SVNKit 1.7

There's the 'incoming' branch that keeps the pristine unmodified
upstream source code, then there's the master branch that keeps track of
the locally maintained version.

So to bump up the dependency, the process involves:

1. checking out the incoming branch
2. wipe out the working copy (so that we won't have any left-over files
    that are deleted in the upstream.)
3. get the pristine source tree of the upstream at a released version
4. commit this new tree.
5. merge the incoming branch into the master branch, resolving
    conflicts. for conflicts, "git annotate" tells you the context
    of changes.
6. 'git diff incoming master' gives you the current changes.



> I'd like to take this opportunity to point out again that using a
> patched library is *NOT* a good idea and we should try to see how the
> Hudson guys solved it in this case.

There's no disagreement there, but those changes are there for reasons,
and it takes some efforts to push them upstream.

I looked at the current diff [1] and there are several things here:

- remoting related changes: making classes serializable, and recording
   keys by its content, not by file name.
- hook mechanism in the authentication.
- error handling improvement, where SVNKit tends to throw away some
   details.
- authentication related bug fixes.

Let me post this to the upstream and get the conversation started...

>
>
> cheers
> Christoph
> .
>

[1] https://github.com/jenkinsci/svnkit/compare/incoming...master
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins

[kohsuke Kawaguchi (CB)]

The license [1] is compatible with MIT, in the sense that the combined
work of MIT and TMate license can be used without violating neither
licenses (just by putting all the necessary attributions.)


[1] http://svnkit.com/license.html

On 04/26/2012 07:45 AM, nicolas de loof wrote:
> Olivier explained me the licensing issue with svnkit 1.7, with "TmateSoft
> License" is not compatible with Jenkins MIT as it requires all derivative to
> follow "complete source code for your application must be available and freely
> redistributable under reasonable conditions"

It depends on the interpretation of the "reasonable conditions", but if
you agree that the redistribution conditions of the MIT license
(attribution) is reasonable (and if not, nothing can be reasonable?),
then the combined derivative work (jenkins.war) satisfies the
requirements of the TMate license.

And interested parties can always drop subversion.hpi from Jenkins core.

> MIT let you do whatever you like with jenkins, this would require a license
> change, mostly GPL
>
> This wouldn't apply if subversion is handled by another plugin, separated from
> jenkins core distribution. Would be also a good opportunity to get rid of those
> forks (during merge, I had to tweak the svnkit fork due to our for on trilead-ssh !)
>
> Maybe it's time for us to deprecate the subversion plugin. Not sure how to
> handle backward compat, maybe core could keep a fake subversion plugin to
> automatically install the (new) svn-plugin on first usage, like OSX Lion does
> for java runtime
>
> wdyt ?
>
>
> 2012/4/26 nicolas de loof<[hidden email]
> <mailto:[hidden email]>>
>
>      Fully agree about patched libraries,
>
>      in the meantime, I've been inspired by the merge done by "centic"
>      on JENKINS-11933 and I'm finalizing a merge for svnkit 1.7.4 to our fork
>
>
>      2012/4/26 Olivier Lamy<[hidden email]<mailto:[hidden email]>>
>
>          What about having an other subversion plugin (not bundled with core
>          for license reason) called svn-1.7-plugin and which use svnkit 1.7 ?
>
>
>          2012/4/26 Christoph Kutzinski<[hidden email]<mailto:[hidden email]>>:
>           >  Hi,
>           >
>           >  in case no one else has mentioned, there are currently a lot of
>          complaints and a lively discussion in
>          https://issues.jenkins-ci.org/browse/JENKINS-11381 why Jenkins still
>          doesn't support svn 1.7 now that SVNKit 1.7 is released.
>           >
>           >  I would fix this myself, but I don't know what the Jenkins specific
>          patches to SVNKit are and how to apply them to SVNKit 1.7
>           >
>           >  I'd like to take this opportunity to point out again that using a
>          patched library is *NOT* a good idea and we should try to see how the
>          Hudson guys solved it in this case.
>           >
>           >
>           >  cheers
>           >  Christoph
>
>
>
>          --
>          Olivier Lamy
>          Talend: http://coders.talend.com
>          http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins

[nicolas de loof-2]

On 04/26/2012 07:45 AM, nicolas de loof wrote:

Olivier explained me the licensing issue with svnkit 1.7, with "TmateSoft
License" is not compatible with Jenkins MIT as it requires all derivative to
follow "complete source code for your application must be available and freely
redistributable under reasonable conditions"

It depends on the interpretation of the "reasonable conditions", but if you agree that the redistribution conditions of the MIT license (attribution) is reasonable (and if not, nothing can be reasonable?), then the combined derivative work (jenkins.war) satisfies the requirements of the TMate license.

And interested parties can always drop subversion.hpi from Jenkins core.

Right, we are not lawyers, and definitively don't want to be. It's not a reasonable world :)

[Wino Tu]

Hi,

If I can connect to thread. 

@Koshuke

Have you checked pending pull requests on github for subversion-plugin. Will those changes be included in 1.40 release with svn kit 1.7 ?

On Wed, May 9, 2012 at 2:52 PM, nicolas de loof <[hidden email]> wrote:

On 04/26/2012 07:45 AM, nicolas de loof wrote:

Olivier explained me the licensing issue with svnkit 1.7, with "TmateSoft
License" is not compatible with Jenkins MIT as it requires all derivative to
follow "complete source code for your application must be available and freely
redistributable under reasonable conditions"

It depends on the interpretation of the "reasonable conditions", but if you agree that the redistribution conditions of the MIT license (attribution) is reasonable (and if not, nothing can be reasonable?), then the combined derivative work (jenkins.war) satisfies the requirements of the TMate license.

And interested parties can always drop subversion.hpi from Jenkins core.

Right, we are not lawyers, and definitively don't want to be. It's not a reasonable world :)