Hosting request for svn-commit-plugin

[Christian Haug]

Hi

GitHub URL: https://github.com/cjhaug/svn-commit-plugin
GitHub username: cjhaug
jenkins-ci.org username: cjhaug
Description: Perform Subversion commit on successful builds.

Regards Chris

[Kanstantsin Shautsou]

Have you tried PR/integrate it into existed subversion plugin? 

[ch]

No.

[ch]

Don't think that the commit action shall be integrated into existing subversion plugin. There are other subversion based plugins available, e.g. svn-tag-plugin, which used a similar approach.
Any news about the hosting request?

[Oleg Nenashev]

CC'ed the Subversion plugin's owner. I think it's OK to create new SVN plugins for new features. Current SVN plugin is monstrous and needs much refactorings so I would not vote for adding new features there. 

BTW it would be great to merge similar actions into the same plugin. Probably SVN Tag and SVN Commit publisher could live together even if the plugin's ID becomes vague. WDYT?

среда, 16 сентября 2015 г., 10:52:22 UTC+3 пользователь ch написал:

[ch]

For me it's fine to integrate the svn-commit publisher to svn-tag-plugin (CC'ed the svn-tag maintainer)

[Manuel Jesús Recena Soto]

Hello,

In Subversion Plugin we are trying to reach a stable version of this
plugin. For that, we are releasing only revision versions: 2.5.1,
2.5.2, 2.5.3.
If one includes new features the work will be more complicated.

In my opinion, this kind of specific features should be in separated
plugins but using a API expose by Subversion Plugin.

As Oleg said, the source code of Subversion Plugin is not very well
organized but we are working to improve this.

However, I disagree with developing new plugins if Subversion Plugin
includes the functionality. For example, make a tag (SVN Tag Plugin).
It causes confusion for users.

Regards,

--
Manuel Recena Soto
* manuelrecena.com [/blog]
* linkedin.com/in/recena

[Kanstantsin Shautsou]

Manuel, having useful feature in plugin without providing API will help in future exclude hell after some refactoring as you will be able to handle code/classes migration at once.

For example git-plugin now can’t strip BuildData from builds as it already used in all trigger plugins in weird ways.

Of course it can add load for you, but you can accept new features in master. For example, git-plugin maintained 2.2.x for hot fixes and master for newer features. 

-- 
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/F03ZaoCbv20/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-UocG%3DF8y%2Bs6utSViC2EwLHvD4%2BtebKQWKAAcDrVsXt6rug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Manuel Jesús Recena Soto]

Kanstantsin, I agree. It is a different point of view. Perfectly valid.

My concern is to block new features while we reach a stable version.

If a new plugin is created, its wiki page should describe clearly the
goals and functionalities.

Regards,

> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/5BEAC448-B9D8-4690-A2A6-95BDE024342A%40gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[ch]

I added a feature description at https://github.com/cjhaug/svn-commit-plugin
The goal of the plugin is to provide a postbuild step to execute svn commit for successful builds. The plugin is able to commit changes (changed, added or deleted items) in a svn working-copy.

What can be the next step to provide this feature?

Regards Chris

[Kanstantsin Shautsou]

If Manuel doesn’t reject having this feature in subversion-plugin, then you can prepare PR and wait end of stabilisation when feature merging window will be open.

Until this you can use patched version that you will be able to pick from PR builder.

In comparison git-plugin also allows doing such features in git-plugin.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6e2cccdd-e922-45df-b071-1798e2bf6ffd%40googlegroups.com.