On Aug 18, 2012, at 8:21 AM, Mike Dubman <mike.o...@gmail.com> wrote:
> re item (5): > > The current svn tree can be set as read-only and serve as a reference for old > commit numbers. > It is rarery used anyway to search through historic commit numbers and can be > done in read-only historic tree. I use it a lot for old commits, but agree it is read-only for that purpose. > > All other items can use svn interface of guthub and stay w/o any change. Yeah, we've had experience with svn to git - no thanks! > > It is pretty minor change (mostly mental) and pretty big gain Guess we can agree to disagree - I found git to be awkward and a royal pain, especially when someone commits without doing a rebase (which happens a lot). No thanks. > > > > > On Sat, Aug 18, 2012 at 3:46 PM, 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 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
