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
