Re: Release 3.0 merge into trunk

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,

Re: Release 3.0 merge into trunk

> On Sep 22, 2015, at 1023AM, Greg Trasuk wrote: > > 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 “

Re: Release 3.0 merge into trunk

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 th

Re: Release 3.0 merge into trunk

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 switch

Re: Release 3.0 merge into trunk

+1 on moving to git. +1 on doing this before a 3.0 release if we want to maintain history from the trunk. Bryan Thompson Chief Scientist & Founder SYSTAP, LLC 4501 Tower Road Greensboro, NC 27410 br...@systap.com http://blazegraph.com http://blog.bigdata.com http://mapgr

Re: Release 3.0 merge into trunk

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 th

Re: Release 3.0 merge into trunk

I concur, all my work, and clients, have moved to git for the very same reason. Dawid On 22/09/2015 13:31, 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

Re: Release 3.0 merge into trunk

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, Se

Release 3.0 merge into trunk

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.