This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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.
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/