I suspect it’s obvious already, but I’m in favor of moving to a single git repo and stopping there unless and until we find it quite inconvenient.
A million thanks Benson for doing the work. thanks david jencks > On Oct 27, 2015, at 10:07 AM, Benson Margulies <bimargul...@gmail.com> wrote: > > On Tue, Oct 27, 2015 at 10:02 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> Am 27.10.15 um 14:52 schrieb Benson Margulies: >>> On Tue, Oct 27, 2015 at 9:51 AM, Carsten Ziegeler <cziege...@apache.org> >>> wrote: >>>> Am 27.10.15 um 14:28 schrieb Benson Margulies: >>>>> As a volunteer of record, I have a preference at this point for >>>>> flipping the entire repo. It's not zero work; all the <scm/> elements >>>>> have to be edited, and release plugin config adjusted, for the maven >>>>> plugins. But that's very straightforward. Once we get this much done, >>>>> we can then start to move things to their own repo. >>>> >>>> What does it take to get a new git repo setup? Just in INFRA jira issue? >>> >>> Yes. There's a particular form of that JIRA that says, >>> >>> 'please convert our mirror to a writable repo and set SVN readonly' >>> >>> as opposed to >>> >>> 'please create a new, empty', repo. >>> >>> The 'all-at-once' plan uses the first option. >>> >> >> Right, understood and sorry to ask again, but if we do the all at once >> plan and want to split something into another new git repo, what does it >> take then? > > For each new repo, a JIRA asking for a new repo, and we move the > content ourselves. > > >> >> Carsten >> >>>> >>>> Regards >>>> Carsten >>>> >>>>> >>>>> ___However___, I'm willing to take up any other work plan that the >>>>> group agrees upon. >>>>> >>>>> On Tue, Oct 27, 2015 at 9:11 AM, Ferry Huberts <maili...@hupie.com> wrote: >>>>>> >>>>>> >>>>>> On 27/10/15 13:45, Carsten Ziegeler wrote: >>>>>>> >>>>>>> Looking at this thread, there seems to be no one really against moving >>>>>>> to git. >>>>>>> >>>>>>> When it comes to moving, we have three options: >>>>>>> >>>>>>> a) create a single git repo >>>>>> >>>>>> >>>>>> I'd start here. >>>>>> It's the simplest and lowest risk thing to do, doesn't break your >>>>>> parent-pom >>>>>> hierarchy, etc. >>>>>> >>>>>> It merely switches the VCS. >>>>>> >>>>>> And then work from there, try out different solutions for your parent-pom >>>>>> hierarchy, releasing, etc >>>>>> >>>>>> You can always split out parts of the tree later while preserving >>>>>> history. >>>>>> Git doesn't mind and has great tooling to do that. >>>>>> >>>>>> >>>>>>> b) create git repos by functional modules >>>>>>> c) create a git repo for every artifact >>>>>>> >>>>>>> Depending on which variant we pick, the more work it is to get >>>>>>> everything moved. Therefore apart from deciding for the option it >>>>>>> depends on a volunteer to drive this thing. >>>>>>> >>>>>>> I'm unsure on how we come to a decision on the option. I think all >>>>>>> arguments are on the plate and there is little use in reiterating these >>>>>>> in slightly different fashions. >>>>>>> >>>>>>> The thing I don't know is, how much effort it requires to >>>>>>> request/create/setup another git repo, e.g. if we start with a) and >>>>>>> there is a desire to create a separate repo for something. (I know the >>>>>>> git commands to move a subtree to a different repo, therefore I'm just >>>>>>> asking about the effort on the infra side) >>>>>>> >>>>>>> Regards >>>>>>> Carsten >>>>>>> >>>>>> >>>>>> -- >>>>>> Ferry Huberts >>>>> >>>> >>>> >>>> -- >>>> Carsten Ziegeler >>>> Adobe Research Switzerland >>>> cziege...@apache.org >>> >> >> >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org
