My mistake. I originally wrote “If we want to keep our linear commit history (i.e. avoid a huge merge commit), all of the commit hashes will have to change”. I believe that is a true statement. I shouldn’t have tried to simplify it.
> On Nov 10, 2021, at 3:46 AM, Dmitry Sysolyatin <dm.sysolya...@gmail.com> > wrote: > > 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 <jhyde.apa...@gmail.com> 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 <zabe...@gmail.com> >> 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 <ppoze...@gmail.com> wrote: >>> >>>> +1 for a single repo. >>>> >>>> Вт, 9 нояб. 2021 г. в 19:22, Vladimir Sitnikov < >>>> sitnikov.vladi...@gmail.com >>>>> : >>>> >>>>> 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 >>>>> >>>> >> >>
