+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://bigdata.com> http://mapgraph.io Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints APIs. Blazegraph is now available with GPU acceleration using our disruptive technology to accelerate data-parallel graph analytics and graph query. CONFIDENTIALITY NOTICE: This email and its contents and attachments are for the sole use of the intended recipient(s) and are confidential or proprietary to SYSTAP. Any unauthorized review, use, disclosure, dissemination or copying of this email or its contents or attachments is prohibited. If you have received this communication in error, please notify the sender by reply email and permanently delete all copies of the email and its contents and attachments. On Tue, 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. >>> >>> >>
