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 <[email protected]> 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 <[email protected]> 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. >>> >>
