On Oct 14, 2016 5:38 AM, "Vladimir Voskresensky" < [email protected]> wrote: >. > > In this context one repo has advantage as well, otherwise feature/issue branches have to be created in multiple repos. >
I don't see it a bad thing to have to create multiple branches across repos. We do that, and we name them the same thing. In almost all cases that will be fairly minimal, like 2 repos, some or many, 1 repo, and then every now and then a few, with all being some very massive refactor of something impacting every module, but that being an extreme rarity. That all sounds manageable to me. Say groovy support needs a new feature, then perhaps Java, Core, and Groovy get a branch. As Groovy support gets better cleaned up, along with Java and others, to have less friend and awkward dependencies, then fewer branches will be needed most of the time. The devs working on it before then need to merge Core, then Java, then Groovy. To me it forces everyone to better think out changes they make at a modular level, and keeps the repos much smaller. Say it is a simple fix or addition to Groovy, or the modularity of things is fixed, then only Groovy would get the branch. Keeping repos as small as possible also makes them work with other tools, like CLI status tools, quite faster. I have some bash tools setup in my bashrc, and NB is the only repo out of all OSS and commercial sources I have which causes a pause after every action I take on the CLI as it inquires about the hg repo status, and that includes Tomcat, the entire Spring Framework, and Qt on a beast of a machine with a blazing SSD. It is also the only repo I work with which times out from time to time. So, I think there are various reasons massive repositories are not practical. I do see your point on some things being easier in a single repository however. I suggest we start a section on the wiki page with pros and cons of both approaches, then we drill down through them, and we mark off or annotate the ones which sound good but have negatives or are not good/easy within the new infrastructure. Either way, we may find a single repository improbable or unlikely. Some comments on infra, plus GitHub limits, already suggest it is unlikely to be feasible. https://help.github.com/articles/what-is-my-disk-quota/ I have written them. I have not yet responded to their response which didn't say one couldn't get a bigger repo sign off, but did ask us to trim out as much as possible as well as old history to see what the size then looks like. I haven't played with that yet, so I don't have enough info to follow up. Wade
