And it takes .3 secs to switch your workspace between your two branches/tags …
Don’t forget that a lot of things that are heavy in SVN are feather weight in
Git.
Kind regards,
Peter Kriens
> On 26 okt. 2015, at 10:03, Carsten Ziegeler <[email protected]> wrote:
>
> Am 25.10.15 um 17:12 schrieb David Jencks:
>> 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).
>
> But if you to look at two modules in detail, like .e.g. a specific tag
> or branch of event admin and a tag/branch of metatype, you can't do this
> with a single git repo. You can only see one or the other.
> Therefore I don't think a single git repo is a good thing.
>
> Carsten
>>
>> 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
>>>>>>>
>>>>>>>
>>>
>>
>>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]
