Just to be clear, I agree with Pat here - stay with svn for the initial 3.0 release. If someone’s up for the challenge, try to merge qa-refactor-namespace into trunk. Alternately, just go ahead and replace trunk with qa-refactor-namespace, as I described below.
Greg Trasuk > On Sep 22, 2015, at 10:52 AM, Patricia Shanahan <p...@acm.org> wrote: > > One concern I have with moving to Git before Release 3.0 is the tension > between really thinking through the Git move and getting 3.0 out quickly. > > On 9/22/2015 7:23 AM, Greg Trasuk wrote: >> Apache’s Git support is just fine, and includes the ability to accept >> pull requests from Github, in a way that suits our need to ensure >> code provenance. The River Container work that I did was in the Git >> repository >> https://git-wip-us.apache.org/repos/asf/river-container.git. >> >> I’m all for switching to git, but we need to actually discuss it and >> work out the desired workflow and project structure. For instance, >> git doesn’t really encourage long-lived branches in a repository. >> So, should we have separate repositories for the 2.2 and 3.0 >> branches? Should we split out reggie, outrigger, JERI, etc into >> their own repositories/deliverables? Should we have a set of >> repositories that reflect our release engineering processes? i.e. a >> development repo, QA repo, release repo, etc? >> >> Simply “switching to git” and then having one big canonical git >> repository that we use exactly the same way as we use svn doesn’t >> seem to offer many advantages, really. If the argument is “but then >> we could take Github pull requests”, well, we can already do that >> with the git mirrors that are there already. >> >> As far as “svn gets really messy for that kind of merge”, I’m not >> convinced that’s a tool issue - the fundamental problem is that the >> qa-refactor branch has diverged from the main branch for years >> without a release or much attention from anyone but Peter, blowing >> away the “develop on trunk” philosophy, and making “diffs” impossible >> to evaluate. No tool is going to help that. We simply need to either >> go through it revision by revision, or just accept it as “the way >> forward”. We’ve decided to accept it. >> >> For now, the current “jtsk/trunk” is an unknown factor as much as >> “jtsk/skunk/qa-refactor-namespace/trunk”. I’d suggest renaming >> “jtsk/trunk” to “jtsk/abandoned” or something, then rename >> “jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release >> from there. That’s the path of least bikeshedding. >> >> Cheers, >> >> Greg Trasuk >> >> >>> On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <p...@acm.org> >>> wrote: >>> >>> For moving to Git, see http://www.apache.org/dev/writable-git >>> >>> Is the support provided sufficient? How do committers in general >>> feel about moving River to Git? If it is a good idea, should we do >>> it before Release 3.0? The alternative might be to rename the >>> current SVN branch and release from there. >>> >>> On 9/22/2015 4:31 AM, Bryan Thompson wrote: >>>> SVN gets really messy for this sort of thing. We wound not >>>> bringing a project with a large delta back to the trunk because >>>> of these issues and just did releases from branches after that. >>>> >>>> What kind of support does Apache offer for switching to git? >>>> That might be easier. >>>> >>>> Thanks, Bryan >>>> >>>> On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> >>>> wrote: >>>> >>>>> I think the next thing we need to do to make Release 3.0 a >>>>> reality is to merge it into the trunk. >>>>> >>>>> If you agree, I would like opinions on the best way to go about >>>>> it. Ideally, we will preserve revision history for modules that >>>>> have moved from one directory/package to another. >>>>> >>>> >>
