What exactly are you trying to solve ? To safe a few hundred kilos of source code not being fetched, but to push the complexity of the build, dependencies, and testing elsewhere? What's the clear win if you have separate repos?
Cos On August 22, 2015 5:28:58 AM PDT, Raul Kripalani <[email protected]> wrote: >On Fri, Aug 21, 2015 at 4:47 PM, Vladimir Ozerov <[email protected]> >wrote: > >> 1) We have 4 distinct parts: Java supporting code, common CPP/JNI >layer >> which depends on Java, .Net implementation which depends on Java and >JNI, >> CPP platform implementation which depends on Java and JNI. And very >often >> it is necessary to update several of them in scope of a single >ticket. It >> will be a nightmare to update them in different repos - tons of >patches >> and/or pull requests. >> > >I see what you mean; if I understood, it's a matter of (1) convenience >and >(2) being able to push commits that contain all changes to support a >given >functionality across all platforms. > >Have you considered Git Subtrees? With that approach I think you can >get >the best of both worlds (separation in different Git repos, and mapping >of >"satellite" repos into directories of a core repo). In my mind, we >would be >having 3 repos: > >* Repo "ignite" => Ignite (Java) + CPP/JNI layer. This is essentially >Ignite + the contract and interop layer for other languages to leverage >Ignite. >* Repo "ignite-cpp" => platform implementation for Ignite in C++. >* Repo "ignite-dotnet" => platform implementation for .NET. > >The ignite repo would map the ignite-cpp and ignite-dotnet repos into >the >source tree via git subtree. > >Considerations: > >* Folks only wanting to interact only with ignite's Java code would not >need to fetch the ignite-cpp and ignite-dotnet repos. Most people will >fall >in this category, I assume. >* Git subtree automatically takes care of splitting commits that span >multiple repos, for them to be applied individually to each repo. >* Tagging commits with JIRA ticket ids allow us to group commits across >a >number of repos under the "umbrella" of a single functionality. > >For those people who are not familiar with Git subtrees, this is a nice >walkthrough: [1]. > >[1] https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844 > >*Raúl Kripalani* >Apache Camel PMC Member & Committer | Enterprise Architect, Open Source >Integration specialist >http://about.me/raulkripalani | >http://www.linkedin.com/in/raulkripalani >http://blog.raulkr.net | twitter: @raulvk
