> Actually, it is possible to preserve the history of commits when you merge > two repos -
You can keep the history, but the hashes will necessarily change because they are based on a different parent. So it will be possible to see the changes, but the hashes would reference the old Avatica repository which would no longer be active. -- Michael Mior [email protected] Le mer. 10 nov. 2021 à 06:47, Dmitry Sysolyatin <[email protected]> a écrit : > > 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 > > >>> > > >> > > > >
