As I understood it, they would create a new 1.7 branch and use git2svn to merge into it - i.e., there would be a new 1.7 branch that had their changes in it. The GK could then use "reintegrate" to bring those changes into the official 1.7 branch.
On Oct 29, 2013, at 7:41 AM, Dave Goodell (dgoodell) <dgood...@cisco.com> wrote: > 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 <mi...@dev.mellanox.co.il> 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) >> <jsquy...@cisco.com> wrote: >> 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
