While working on bnd and OSGI at github I’ve become quite attached to the triangular workflow model. (cf https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows <https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows>) I probably should know already, but does anyone know how practical it is to do this with apache git and developer branches at github?
I don’t know if apache git is at version 2.5 yet, but from the above link it looks like the new worktree feature may provide an alternate solution to the multiple-branches problem. david jencks > On Oct 25, 2015, at 12:12 PM, David Jencks <[email protected]> wrote: > > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>>> 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 >>>>> <[email protected]> wrote: >>>>>> On 24 October 2015 at 11:36:03, Benson Margulies >>>>>> ([email protected](mailto:[email protected])) 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 >>>>>> >>>>>> >> >
