Multiple SCM Instance Forking/Merging/Requests/etc...

[Chuck Boecking]

Hi Team,

I would like to open the discussion about forking/merging projects between different SCMManager instances.

I work with a bunch of ERP integrators for iDempiere (open source ERP). We share a lot of code with each other; however, we all want to maintain our own SCM instances. I believe it would be beneficial to be able to fork/merge/etc... between the instances. Do you agree? Is this something you ever envision tackling?

Regards,

Chuck Boecking

www.chuckboecking.com

[Sebastian Sdorra]

Hi chuck,

Such a feature is currently not on our todo list. How should look such a feature in detail? A fork button which opens a dialog from a list of connected scm-manager instances?

Sebastian

--
You received this message because you are subscribed to the Google Groups "scmmanager" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scmmanager+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chuck Boecking]

Generally speaking, I think the use cases would follow bitbucket's fork/pullRequest architecture. Here are my thoughts.

• You would have a list of linked SCM instances. 
• You would give permissions to repositories based on Server.User nomenclature. Example: CompanyA.RoleA or CompanyB.UserB.
• UserB would initiate a fork of a remote project.
• UserB could merge in changes from the remote system on an as-needed basis.
• UserB would initiate a pull request to the remote system when UserB is ready to share change sets back to the original repository.
• The user of the original repository would review the diff and either accept or deny the pull request. An accept would result in a merge.

My business case is where you have multiple development teams collaborating on a common application (each team with its own SCM). Another business case is:

• Let's assume I am a software tools provider. 
• I write open source software, and I charge a monthly fee to stay connected to my repository.
• I could use the above solution to provide access to my code to another team without giving them direct access to my repo.

The short version is that the above architectures helps multiple 'teams' collaborate in a more formal distributed fashion.

2 cents - I hope this helps!