That would be fine - thanks! When you do the export, please setup the "svn ignore" properties after you do your test build. Those don't get set by git, of course.
On Oct 29, 2013, at 7:28 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote: > yes, this is what I tried to suggest :) > we export our git branch to svn in openmpi.org for review. > > > On Tue, Oct 29, 2013 at 3:34 PM, Joshua Ladd <josh...@mellanox.com> wrote: > I think the community’s concerns are valid. What Mike is articulating is that > we already maintain a “1.7 ready” OSHMEM branch internally. I think it should > be a simple procedure to do as Brian and Ralph are suggesting and branch off > of 1.7 in SVN and apply our patches. We can do this. > > > > Josh > > > > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Barrett, Brian W > Sent: Tuesday, October 29, 2013 9:29 AM > To: 'Open MPI Developers'; 'Open MPI Developers' > Subject: Re: [OMPI devel] [EXTERNAL] Re: SHMEM v1.7 merge proposal > > > > Yes, what's important is that 1) we all have a way to review the final merge > (which means a public branch) and 2) it's easy for the GK to merge. > > Brian > > > > Sent with Good (www.good.com) > > > -----Original Message----- > From: Jeff Squyres (jsquyres) [jsquy...@cisco.com] > Sent: Tuesday, October 29, 2013 04:36 AM Mountain Standard Time > To: Open MPI Developers > Subject: [EXTERNAL] Re: [OMPI devel] SHMEM v1.7 merge proposal > > > > I think Brian's point is that it should be a SVN branch. > > > On Oct 29, 2013, at 3:27 AM, Mike Dubman <mi...@dev.mellanox.co.il> 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 <bwba...@sandia.gov> > > 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 > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
