Hi, In the 12+ years I’ve been working on apache projects I can’t recall any time when I’ve wanted to simultaneously check out different branches of modules of the same top level project. Therefore, unless anyone has actual contrary experience, I’d be in favor of trying a single git repo and refining it into multiple repos if we discover problems in real life use. (I have wanted to check out different branches of the same project simultaneously, but with git this is not helped by more repos).
thanks david jencks > On Oct 25, 2015, at 2:47 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I am not sure if one git repo for everything would be a good idea. The main > reason is that in git (unlike in subversion) each branch and tag you do > contains all the other unrelated projects too. > I think it would also be quite difficult to checkout a state of the repo > where you need bundle A in branch A1 and bundle B in branch B2. Probably this > would mean that you need to checkout two instances of the repo > to have both branches visisble at the same time. You would then also have to > be really careful to not pick a project from the wrong checkout as it would > be in kind of an undefined state there. > > The other solution of having one git repo per bundle also seems to be quite > difficult to manage as you need to checkout and sync every such checkout in > the correct way. I have seen a project that does this at a customer and it is > not very easy to work in this structure. > > In the Aries project we went for kind of a compromise. > > We aim for releases by subproject. So each subproject can go into one git > repo. > The advantage is that each tag in git really covers the whole subproject. So > from the git side this is natural. > > The downside is of course that in many cases bundles are released that did > not change at all. > We make sure the package versions are done with semantic versioning. So from > the OSGi point of view the versioning > is still working as before. > > At the moment we have not yet done the migration to git but it is planned. We > are currently moving each subproject to the release by subproject model > gradually. > Theoretically we can then move each subproject to git independently. I am not > sure though how to move the change history over in that case. > In any case the Aries JPA project is the first one that is fully converted to > the release by subproject model if you want to take a look. > https://github.com/apache/aries/tree/trunk/jpa > > Christian > > Am 24.10.2015 um 23:32 schrieb Benson Margulies: >> On Sat, Oct 24, 2015 at 4:21 PM, David Jencks <david.a.jen...@gmail.com> >> wrote: >>> I like having several felix subprojects open in one eclipse instance at >>> once, which the current svn structure facilitates. Having just one git svn >>> rebase to run is nice. Is there a way to stitch together several smaller >>> git repos that would work similarly? Not knowing how to do this, I am >>> starting to lean towards one big repo. >> Well, there are git submodules. But I hate to take everyone into that >> rabbit hole. I think we should aim to start with one big repo and >> assume we can tame the maven-release-plugin to start with. >> >> >>> FWIW, I’m hoping to move DS onto a gradle based build soon. >>> >>> thanks >>> david jencks >>> >>>> On Oct 24, 2015, at 2:51 PM, Benson Margulies <ben...@basistech.com> wrote: >>>> >>>> Greeting, Marcel, >>>> >>>> It's not my intention to try to talk anyone into changing how they >>>> release anything. For the things that are built with Maven, it's my >>>> preference to avoid exercising the maven-release-plugin's feature of >>>> handling multiple released items in a repo, but it's just a >>>> preference. If the acceptable compromise is to have less repos than >>>> releasable items (possibly as few as one repo), I'd personally rather >>>> do that than not move to git at all. >>>> >>>> regards, >>>> >>>> benson >>>> >>>> >>>> On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans >>>> <marcel.offerm...@luminis.nl> wrote: >>>>> On 24 October 2015 at 11:36:03, Benson Margulies >>>>> (ben...@basistech.com(mailto:ben...@basistech.com)) wrote: >>>>> >>>>>>> So I would definitely argue against getting a Git repository per bundle. >>>>>>> Per subproject sounds like the right granularity to me. >>>>>> If a subproject is released all at once, then we're completely >>>>>> agreeing. If not, then your preference means exercising the >>>>>> occasionally squishy part of the release plugin; maybe it will get >>>>>> fixed once and for all. >>>>> So for the dependency manager we reasoned as follows: >>>>> >>>>> 1) When talking about releases within Apache, we are talking about source >>>>> code. Releasing that a subproject at a time makes sense to me as the >>>>> code, even if it ends up in different bundles, clearly belongs together. >>>>> >>>>> 2) Binary releases are a matter of convenience and “what is convenient” >>>>> depends a lot on where you’re coming from. A lot of people would argue >>>>> that putting a binary in Maven is convenient, but there are definitely >>>>> other options. The binary releases also don’t have to have a 1:1 mapping >>>>> with the source, so we can have N bundles being put in Maven and other >>>>> repositories all from the same source release. >>>>> >>>>> Greetings, Marcel >>>>> >>>>> >
