On Sat, Aug 22, 2015 at 5:56 PM, Konstantin Boudnik <[email protected]> wrote:
> 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? Nah, not really the download size. That's secondary. You think putting each project in its own repo and linking them via Git subtrees is the more complex than keeping it all in one repo?! I think that's an early conclusion. There are things we haven't talked about, e.g. project lifecycles, release lifecycles, continuous integration, releases for different processor architectures and/or OS (C++), etc. In reality, source code structure should go hand-in-hand with the type of organization we pursue, so we should discuss that first. Hosting each project in a separate repo (and linking them via Git subtrees) is beneficial for several reasons. Off the top of my head: * Independent – but related – lifecycles for each subproject. While all projects are intertwined, being able to release .NET, CPP, Ignite Java separately is fundamental for bugfixing. If the community hasn't talked about this, now's a good idea to define a versioning policy and/or scheme. Can each implementation evolve separately, i.e. with independent micro versions (semver) if bugfixes are to be released ASAP for just a single platform? Or do we keep all versions in sync and wait for a simultaneous release? (à la Eclipse). * Converging different build systems, each with its own release system, for a different technology, inside the same repo may be confusing and counter-intuitive for users. * If you want to fix a .NET or CPP bug, and want to create a branch exclusively for that platform, I don't see why you should be branching all off Ignite for all platforms. * Similarly, if we are allowing independent (but related) lifecycles for each part, I don't see why a tag for a .NET bugfix, e.g. ignite-dotnet-1.4.5 release should contain all of Ignite including CPP and Java, especially if those versions are still on 1.4.3. That's plain confusing, and with Git one cannot tag a specific region of the tree. Now from my personal experience: once you start cramming up several heterogeneous projects that satisfy conditions like... (a) targeting different user bases / consumers (albeit some organisations may use all 3 simultaneously). (b) using different technologies and programming languages. (c) may evolve with slightly different (but related) lifecycles. (d) requiring different build systems with distinct CI setups each (for .NET you'll need a Windows node on TeamCity). (e) different release systems (e.g. for CPP you'll need to likely an artifact per architecture). (f) attracting contributors with different skills (few people are proficient enough to work on Java, .NET and C++ simultaneously and effectively). ... you're likely more inclined towards separating the code bases (and linking them) rather than hosting everything inside one big repo. Regards, *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
