Yeah, even if someone volunteered to do the conversion work, we wouldn't get agreement on making such a change. Some of us hate git (myself included), some feel similarly about mercurial, etc.
Unfortunately, we've seen enough pain from git+svn to definitely not want to go that route. The current situation seems to be the best compromise, and works tolerably well (minus the odd, but rare, burble). On Aug 18, 2012, at 5:46 AM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Aug 18, 2012, at 8:27 AM, Jeff Squyres wrote: > >> That's pretty clever, actually (SVN and git effectively together in the same >> repo). Cool! >> >> However, migrating to git has all the same problems that I mentioned in the >> prior email to you. Is Mellanox volunteering to do all the work for >> conversion? > > > I guess I should clarify -- here's what I previously sent to Mike in an > off-list email about converting our main SVN repo to something else (e.g., > Mercurial or Git). #3 is probably moot if we entirely move to github, but it > would be replaced with "migrate all existing users to github" (which is a > fair amount of work, too). > > ----- > We have *many* discussions a year or two ago about making Mercurial the > primary repo, not SVN, and ultimately rejected it. There's many issues > involved: > > 1. developer learning curve > --> certainly not the biggest factor, but definitely a factor > --> "rebase" would certainly be a big deal (so that people don't put back a > million intermediate commits) > > 2. adapting all of OMPI's current scripting to use hg (or git) > --> this is a fair amount of work > > 3. getting IU to host git instead of SVN > --> they have a whole management system for SVN: users, permissions, etc. No > such thing exists for git. > > 4. integrating Trac with git. Or migrating to a whole new bug tracker that > supports git. > --> this is an entire conversation in itself. Note that everyone hates > bugzilla. > > 5. re-writing the SVN history to find all references to "rXXX" in commit > messages and replace them with the relevant hg (git) unique commit hash > --> someone would have to figure out how to script that > > So conversion would be a significant amount of work. Instead, we opted for > our current modes of operation, which seem to be working well enough: > > - use the hg+svn or git+svn combo mechanisms to do actual development in > hg/git and then push back up to svn when done > - provide hg (and now git) official mirrors so that people can branch/clone > from there, and then provide patches to commit when done with development > > In short -- I agree with you: moving to 100% hg/git would be nice. But it > would be a lot of work that no one was willing to spend the time to do. > > -- > 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
