We at Pentaho made the migration to Git and GitHub from Subversion and Perforce a few years ago now. At the time we decided to go with multiple repositories (we're at around 100 right now). In retrospect this was a large mistake.
Development often spans multiple repositories creating dependent changes and corresponding pull-requests -a lot of churn on our CI systems. Branching, tagging, version updates, reformatting are all made more complicated. Our build teams have scripts to help with this, but it puts a lot of these tasks out of the range of our single contributors. We've tried to group together related Projects into the same repository, but relationships often change between projects. We explored Submodules to try to provide a unified repository "view", but this was an imperfect solution. And there's the confusion from the community and partners about what to clone, what order to build it in, etc. Go with a single large repo IMO. It's very easy to view changes affecting only a particular subdirectory, cutting-down on the history noise. Similarly the CI SCM plugins are all able to detect which jobs a new commit affects so a single commit doesn't trigger all jobs to build. Regards, -Nick Baker On Tue, Dec 1, 2015 at 6:41 PM, Richard S. Hall <he...@ungoverned.org> wrote: > > > On Dec 1, 2015, at 17:50, Benson Margulies <bimargul...@gmail.com> > wrote: > > > > > https://cwiki.apache.org/confluence/display/~bimargul...@gmail.com/Felix+and+Git > > > > ? > > Seems like a good start, although is that editable by others? > > It seems like other technical issues were raised about the approaches, so > it would be nice to see those added in there by people who have experience. > > I admit, for me, SCM is a necessary evil and not something I get too > exited about. I haven’t seen anything to prefer git over svn or vice versa. > They’re just different hammers for the same nail. > > Still, thinking about the options, it seems like multiple repos creates a > maintenance headache to some degree. For example, line-ending handling is > fairly difficult to get configured correctly in git. By having multiple > repositories, then every repository would have to have this configured > individually, since stuff like that is good to have configured uniformly. > Any changes to how we want things uniformly handled would require manual > propagation of configuration. Of course, this seems like it would be an > issue in any proliferation of repositories (svn or git). > > Or perhaps there is a better way to handle such issues? > > -> richard > > > > > > > On Tue, Dec 1, 2015 at 1:56 PM, Richard S. Hall <he...@ungoverned.org> > wrote: > >> On 12/1/15 13:40 , Carsten Ziegeler wrote: > >>> > >>> Richard S. Hall wrote > >>>> > >>>> Well, the argument to the contrary is perhaps that is makes it more > >>>> difficult for us as a community to have oversight into releases. It > >>>> almost assures us that some/many community members will never checkout > >>>> subprojects that aren't in the repository they normally work. Granted, > >>>> there is no guarantee of this now, since I can just check out what I > >>>> want anyway...but at least it is fairly easy for me to do so now and > it > >>>> becomes more difficult if everyone spreads to their own repos. > >>>> > >>>> So, in that regard, I'm more aligned with Marcel...all or nothing > makes > >>>> more sense. > >>> > >>> Hmm, ok fair point - however, the *all* is the problematic part where > we > >>> couldn't agree on last time (one git repo vs many git repos). > >> > >> > >> But isn't it then incumbent on those wanting such changes to convince > us one > >> way or the other? > >> > >> Personally, I'd rather just have one big git repo if we are going to > switch, > >> if for no other reason than it seems like less overhead. However, I > admit to > >> not really knowing the advantages/disadvantages. > >> > >> Regardless, at a minimum, perhaps someone should create a documented > >> pros/cons list for the approaches. This would at least give us a way to > call > >> a vote where we can feel somewhat informed about the choices (i.e., stay > >> with svn, move to one git repo, move to many git repos). > >> > >> Better than saying, "there is no consensus, so let's just go our > separate > >> ways"... > >> > >> -> richard > >> > >> > >>> > >>> We could still provide a script in the root of svn which checks out the > >>> moved projects from git and gives the same experience :) > >>> > >>> Carsten > >> > >> > >
