On Oct 14, 2016 5:38 AM, "Vladimir Voskresensky" <
vladimir.voskresen...@oracle.com> 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.


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.


Reply via email to