felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david.a.jen...@gmail.com>
Subject Re: git?
Date Sun, 25 Oct 2015 16:51:32 GMT
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 <david.a.jencks@gmail.com> 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 <chris@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.jencks@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 <benson@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.offermans@luminis.nl> wrote:
>>>>>> On 24 October 2015 at 11:36:03, Benson Margulies (benson@basistech.com(mailto:benson@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
>>>>>> 
>>>>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message