Actually, it is possible to preserve the history of commits when you merge two repos - https://stackoverflow.com/questions/17371150/moving-git-repository-content-to-another-repository-preserving-history
On Tue, Nov 9, 2021 at 11:24 PM Julian Hyde <[email protected]> wrote: > Merging the repositories is unnecessary, and a massive waste of time. > > Any supposed “time savings” due to the the merged repositories will be > eaten up by dozens of small issues that will crop up long after the merge. > > I was release manager for Calcite and Avatica this time around and it took > me about a week, because the process had changed since last time I was > release manager. And now we’re going to change the process again? > Absolutely fucking insane. > > Also, we will lose the history of the Avatica source code. All of the > commit hashes for bugs fixed long ago will change. > > At the time that we split the repositories, I was probably against the > idea, because it was work. Now that we’ve split, I am strongly against > recombining the repositories. > > Honestly, people, we have better things to do. > > Julian > > > > On Nov 9, 2021, at 1:03 PM, Stamatis Zampetakis <[email protected]> > wrote: > > > > The two projects have more or less the same release cadence, they're > > maintained by the same community, they're written in the same language, > and > > they use the same build system. > > > > Although I understand the reasons the project was split in the first > place, > > at the moment I tend to agree that having them in the same repo would be > > more practical. > > > > Truth is the merge may require quite a bit of work so we should take this > > into consideration. > > > > If people prefer keeping the projects as they are I am perfectly fine > with > > that as well. I am leaving the decision to those who feel strongly about > > this change. > > > > Best, > > Stamatis > > > > > > > > On Tue, Nov 9, 2021, 7:46 PM Vladimir Ozerov <[email protected]> wrote: > > > >> +1 for a single repo. > >> > >> Вт, 9 нояб. 2021 г. в 19:22, Vladimir Sitnikov < > >> [email protected] > >>> : > >> > >>> Michael> is not proposing to change the > >>> Michael>structure of modules within both projects, merely to have the > >> code > >>> for > >>> Michael>both in a single repository. > >>> > >>> I propose to integrate them into a single build, and keep the set of > the > >>> published jars. > >>> However, the modules and dependency structure could be kept as is. > >>> > >>> We might want to rename folders like > >>> calcite-core > >>> calcite-linq4j > >>> .. > >>> avatica-core > >>> avatica-server > >>> > >>> However, I am not sure it is that important to discuss folder names > now. > >>> The idea is that as you "open Calcite in IDE, you see both Avatica and > >>> Calcite modules" > >>> > >>> Michael>Is there any reason we couldn't have a separate release > schedule > >> if > >>> Michael>both projects are in the same repository? > >>> > >>> A different schedule means Calcite must support at least two different > >>> Avatica versions. > >>> In other words, if we allow clients to update Avatica at their will, > then > >>> we should allow them building Calcite with different Avatica versions, > >>> which implies Calcite test code should succeed for multiple different > >>> Avatica vesions. > >>> > >>> That makes it harder to write tests: we have to execute tests with two > >>> different Avatica releases (or even more than two). > >>> > >>> There are at least two sources for complexity: > >>> > >>> a) We have to write tests that tolerate multiple versions. For > instance, > >>> "if (avatica.18+) {...}" and so on. > >>> That is not really trivial, especially taking into account some of the > >>> tests are created with non-yet-popular > >>> technologies like Quidem where you can't really google solutions. So > the > >>> "trivial" task of "making a test to expect two possible outcomes" > >>> becomes less trivial as you try to pass the version from GitHub Action > to > >>> Gradle to JUnit to Quidem to no-one-knows-which class. > >>> If we support one Avatica version only, that is not needed. We just > patch > >>> the test in Avatica and Calcite and that is it. > >>> Single repo avoids "Gradle vs Quidem" dance. > >>> > >>> b) If we claim that we support 5 different Guava versions, 3 different > >> JDK > >>> versions, 2 different Avatica versions, > >>> then we have to execute 5*3*2 = 30 combinations of the tests. > >>> That is not really a full matrix, however, things get way easier if we > >>> support one Avatica version only. > >>> The amount of tests we need to do during a proper release is much less, > >> and > >>> it is easier to commit > >>> changes that touch Avatica and Calcite at the same time. > >>> > >>> > >>> Vladimir > >>> > >> > >
