In the scm-sync-config plugin, there are 2 SCM API used (and bridged) nowadays :
- Jenkins SCM API : used mainly for authentication
- Maven SCM API : used mainly to provide an abstraction over "standard" scm commands
Problem with SCM API are :
- I don't know them very well (don't think it is well documented either)
- I don't think it is as rich (in terms of abstractions) as the Maven SCM API (I don't think, for instance, that there is a generic method allowing to "commit" things on the repository ... since jenkins doesn't need to commit anything generally .. it only uses scm to checkout source files).
On the SCM API side, problem is not with lack of generic layered methods, but differences in behaviour in these ones.
For instance, update() with svn will do an `svn update` (thus, working copy will be up to date, and ready for subsequent modifications). A svn delete will then be taken into account directly.
Whereas update() with a git impl will only do a `git fetch` (working copy not up-to-date (only origin references are updated)), thus we will need either a 'rebase' or 'merge' to include changes to push them on the upstream remote. These methods don't exist because they are too DVCS-oriented (and couldn't be implemented in non-DVCS scms).
Moreover, changing things in SCM API takes time because adding a generic method needs every scm implementation to provide their impl for this new generic method
This is the reason why I think the better solution will be to implement our own generic impl for plugin needs only
Major
But well, «À cheval donné on ne regarde pas la denture» =
get committed to the Git repository that is supposed to just hold the changes to configuration files. As a result, the Git repository size has grow to over 7 GiB for our project. Given this, I'd say this is a blocker.
