Issue #11741 has been updated by Jon Moss.


Hi Yui,

I apologize for not finding previous Git to SVN discussions on the Redmine issue tracker. I did search for 'git subversion' on the Redmine issue tracker, but only 12 results came back, and none of them were the above mentioned issue 10547. I did try searching for just 'git' in the search engine, but for that search over 2,349 results came back, and I think it's unreasonable to expect someone to be able to sort through all 235 pages of those results.

I am happy to make a small chart comparing Git and Subversion conversion pro/cons, see below. I do think that my plan listed above is fairly concrete with just a few kinks to be worked out (DNS / quantity of servers to be provided). I also think that at this point the argument is more focused on ideology of Git vs SVN rather than the economics/money of making this decision, since the sponsor would be taking care of the cost of servers for us.

### Git to Subversion Pros (Yay Git!)
* Matz has promised both in his 2014 RubyConf, and now at his 2015 RubyConf talk, that Ruby will be moving to Git "soon"
* The other major implementations of Ruby, Rubinius / JRuby, as well as Matz's own mruby all use Git for their version control system.
* Most Ruby projects use Git, for example:
  * Rails / Sinatra
  * RSpec / Minitest
  * Rake
  * RubyGems / Bundler
* The late Jim Weirich said in one of the mailing list discussions you mentioned earlier that, "I have seen the number of contributions to Rake skyrocket after the switch."
* He also said that, "[...] once past the initial learning curve, I'm very happy to be using git and would choose git over svn for any new project where given the choice."
* Git is much more widely used than Subversion, and the Ruby language itself is the only critical Ruby infrastructure project I can think of that uses Subversion
* Ruby already has a Git mirror, why not go "whole hog" and make the full transition over to Git? Seems a bit odd to be supporting both version control systems
* Most online coding tutorials/bootcamps + companies use Git, and do not teach or use Subversion anymore. The Ruby language itself should be promoting industry practices.

### Git to Subversion Cons (Yay Subversion!)
* Ruby has been using Subversion for a while, so all key Ruby contributors know how the tool works
  * Solution: Git is widely used, and there are many tutorials to get up to speed
* Ruby has been using Redmine for a while, so all key Ruby contributors know how the tool works
  * Solution: Gitlab is a tool with great documentation and a great API, so learning should be quick. Gitlab is also much more visually appealing (IMO) as compared to Redmine.
* Subversion is centralized, so all source code is in one place
  * Solution: This makes svn.ruby-lang.org a SPOF (single point of failure). By Git being decentralized, everyone has a copy of all of Ruby's history locally and easily accessible.
(Sorry I couldn't come up with anymore cons, I only use Git, and have not used Subversion before)

Please do let me know if there is anything I can do to help out with this ticket.

----------------------------------------
Feature #11741: Migrate Ruby to Git from Subversion
https://bugs.ruby-lang.org/issues/11741#change-55101

* Author: Jon Moss
* Status: Rejected
* Priority: Normal
* Assignee: 
----------------------------------------
# Git to SVN

Converting Ruby wholesale from Subversion to Git (not necessarily Github!) has been a long time coming, and I think it's finally time to make the switch. Ruby already has an official Git repo up on Github, and the main contributing.rdoc file in that repo is meant for Git, not Subversion. Git is definitely the most popular VCS (version control system) in the Ruby ecosystem, and it's time for the language itself to convert. I propose that Ruby use [Gitlab](https://about.gitlab.com/) to manage its issue tracker, merge/pull request tracker, and the actual Git repository itself. Gitlab is an open source Ruby on Rails that many large corporations have begun to use for Git repository management + related tools. Gitlab also has a CI toolset built right into the core application, so we could also run CI all on the same set of servers. I have contacted and have a sponsor (that's a major Ruby server hosting company) ready to foot the bill for all servers needed to run a cluster of Gitla
 b servers for Ruby.

Below is a preliminary checklist for how to go about the change:

## Actually convert codebase from SVN to Git
  - Either use the **`svn2git`** gem
  - Or clone down the Git repository from https://github.com/ruby/ruby

## Redmine --> Gitlab
  - Contact sponsor [REDACTED] to get GitLab servers spinning, and live (under git.ruby-lang.org, maybe?)
  - Get CI running on Gitlab (start off with Ubuntu Linux)
  - Migrate all issues (open and closed, or just open?) from Redmine to Gitlab via Redmine and Gitlab APIs
  - Begin migrating all pull requests from Github to Gitlab

## Final Transition
  - Post large notice on Redmine website saying that Redmine + Subversion will be deprecated soon
  - After two months (maybe shorter? longer?) close down old Redmine + Subversion servers

I am happy to make adjustments as necessary to the timeline listed above, and to take the lead on this project. Let me know if we want to continue the conversation with the server sponsor and the Ruby core team. <3



-- 
https://bugs.ruby-lang.org/