On Sun, 2015-10-25 at 07:47 +0100, Christian Schneider 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. If you have multiple git subprojects you can tie them into one git repository without resorting to submodules. I've used a tool called gitslave [1] with very good results when splitting a large repository into multiple smaller ones ( 94 at the moment ). gitslave allows you to define a single 'master' repository which minimally needs to hold a .gitslave file which points to the child repositories. You can then use the 'gits' command to run commands over multiple repositories, e.g. * gits populate to create the child repositories * gits pull to run 'git pull' over all child repositoroes * gits push to 'run git push' over all child repositories ... I guess you get the idea. HTH, Robert [1]: http://gitslave.sourceforge.net/ > > 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 > > > > <[email protected]> wrote: > > > > > On 24 October 2015 at 11:36:03, Benson Margulies (benson@basi > > > > > stech.com(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 > > > > > > > > > > >
