Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
From: Oliver Lietz <apache@oliverlietz.de>
To: dev@felix.apache.org
Subject: Re: git?
Date: Mon, 26 Oct 2015 21:17:06 +0100
Message-ID: <2739367.vny9fY6rKH@madness>
User-Agent: KMail/4.14.3 (FreeBSD/10.2-RELEASE; KDE/4.14.3; amd64; ; )
In-Reply-To: <1445851412.8246.10.camel@apache.org>
References: 
 <CALm0H57xUYSOBxTbvhko3WTKoxq-kBePOJV0z872y1evDexc7A@mail.gmail.com>
 <562C7AF7.9090003@die-schneider.net> <1445851412.8246.10.camel@apache.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"

On Monday 26 October 2015 11:23:32 Robert Munteanu wrote:
> 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.

gitslave is no longer maintained, I suggest to look at Google repo[0] at 
least.

Regards,
O.

[0] https://code.google.com/p/git-repo/

> HTH,
> 
> Robert
> 
> 
> [1]: http://gitslave.sourceforge.net/
[...]