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
