river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: Release 3.0 merge into trunk
Date Tue, 22 Sep 2015 14:12:19 GMT
+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
4501 Tower Road
Greensboro, NC 27410
http://blog.bigdata.com <http://bigdata.com>

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 <pats@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 <pats@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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message