Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] SHMEM v1.7 merge proposal
From: Mike Dubman (miked_at_[hidden])
Date: 2013-10-29 10:54:34


We probably will generate single patch with all changes applied in v1.7 for
shmem and create svn branch from 1.7 + patch.

Im sorry, did not mean we port git history from git to svn, it sounds
trouble.
Mike,

I've never personally used git2svn, but my understanding is that it would
require us to essentially "lock" the repository to all other commits while
you are using it, which isn't very friendly to the rest of the community.
 Also, using git2svn probably wouldn't twiddle the SVN merge tracking
metadata correctly.

I think it would be better to simply handle this with "svn merge" and
friends.

-Dave

On Oct 29, 2013, at 6:08 AM, Mike Dubman <miked_at_[hidden]> wrote:

> will it be ok, that once all is ready, we push git2svn branch for this?
>
>
> On Tue, Oct 29, 2013 at 12:35 PM, Jeff Squyres (jsquyres) <
jsquyres_at_[hidden]> wrote:
> I think Brian's point is that it should be a SVN branch.
>
>
> On Oct 29, 2013, at 3:27 AM, Mike Dubman <miked_at_[hidden]> wrote:
>
> > Hi,
> > This is exactly the way we handle it now. We have internal branch on
top of v1.7 with all SHMEM code in it.
> > It runs mtt and other tests.
> >
> > Once we done with all changes - we will provide patch (and branch
direct access if needed) for GK.
> >
> > Kind Regards
> > Mike.
> >
> >
> > On Tue, Oct 29, 2013 at 1:02 AM, Barrett, Brian W <bwbarre_at_[hidden]>
wrote:
> > All -
> >
> > Ralph and I talked today about the logistics of bringing the OpenSHMEM
> > code to the 1.7 release branch, as it's now a fairly large set of
changes
> > from the trunk. What we propose is to follow the same proceedure we
used
> > when merging in the RTE framework change, which is essentially a staging
> > branch. So, Mellanox (as the one filing the CMR) would branch from 1.7,
> > bring the OpenSHMEM changes into that (and hopefully test), and then
file
> > a single CMR for the changes from the branch. If done properly, the GK
> > then only has to merge with --reintegrate and we're set.
> >
> > Let's talk about it on the call tomorrow, but that's the current
proposal.
> >
> > Brian
> >
> > --
> > Brian W. Barrett
> > Scalable System Software Group
> > Sandia National Laboratories
> >
> >
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >
> > _______________________________________________
> > devel mailing list
> > devel_at_[hidden]
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

_______________________________________________
devel mailing list
devel_at_[hidden]
http://www.open-mpi.org/mailman/listinfo.cgi/devel