[
https://issues.apache.org/jira/browse/SCM-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17963818#comment-17963818
]
ASF GitHub Bot commented on SCM-970:
------------------------------------
jira-importer commented on issue #1195:
URL: https://github.com/apache/maven-scm/issues/1195#issuecomment-2964654117
**[Robert
Scholte](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=rfscholte)**
commented
That would imply that ScmProvider would get methods for both distributed and
centralized. I don't think we should go that way, they are to completely
different types that are hard to mix.
I think the question is: should we empty the ScmProvider (and yes, breaking
backwards compatibility. Hence we had to wait for SCM 2.0) and cleanup+move
these methods to the CentralizedScmProvider?
Another challenge is the wording: commit / push / etc. are these terms
accepted as standard by all the scm types?
> Have separate APIs for distributed and centralized version control
> ------------------------------------------------------------------
>
> Key: SCM-970
> URL: https://issues.apache.org/jira/browse/SCM-970
> Project: Maven SCM (Moved to GitHub Issues)
> Issue Type: Improvement
> Reporter: Robert Scholte
> Priority: Major
> Fix For: 3.0.0
>
>
> The nature of these 2 types are very different. The original scm api was
> based on centralized repositories, and the distributed was implemented behind
> those methods, which makes it more complex than required.
> Splitting this will make it easier to make full use of distributed features.
> Keep in mind that plugins like the maven-release-plugin must still be able to
> do their work, but they may need to provide implementations for both tastes
> (unless the original scm-api implements it).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)