SCM/HGtoGit: Difference between revisions

Jump to navigation Jump to search
Line 1: Line 1:
=Migrating from Hg to Git=
=Migrating from Hg to Git/Github=
This page summarizes the benefits, issues, and requirements in a migration from Mercurial (Hg) to Git. The material is grouped by role to allow people to view the information relevant to them. There are really two issues as part of this discussion: migration from Hg to Git and migration from Mozilla hosted systems to Github.
In discussing a migration from Mercurial (Hg) to Git, there are really two issues to address:  
# migration from Hg to Git
# migration from Mozilla hosted to third party hosted (Github) repositories


There are three primary roles that make use of Mozilla's source code management (SCM) systems: developers, release engineers, and IT system admins.
This page summarizes the benefits, issues, and requirements for both #1 and #2. The material is flagged by role to allow people to easily view the information relevant to them.


==Developers==
There are three primary roles that make use of Mozilla's source code management (SCM) systems: developers {{devs}}, release engineers {{releng}}, and IT system admins {{IT}}.
 
==Migration from Hg to Git==
===Benefits===
===Benefits===
* Simplified onboarding for new contributors as Git is better known today than Hg
* Simplified onboarding for new contributors as Git is better known today than Hg {{devs}}
* Git supports new workflows not supported by Hg
* Git supports new workflows not supported by Hg {{devs}}
* Mozilla currently makes use of Hg and Git, consolidation is easier for all devs
* Mozilla currently makes use of Hg and Git, consolidation is easier for all devs {{devs}}
* Better review tools (Gerrit) available for devs
* Better review tools (Gerrit) available for devs {{devs}}
* Simplified debugging (no longer have to debug Hg) {{releng}} {{IT}}
* Simplified management as only one SCM system {{releng}} {{IT}}
===Issues===
===Issues===
* Overhead in having a large number of people learn new tools
* Overhead in having a large number of people learn new tools {{devs}}
* Do the Windows Git tools perform as well as the Hg tools?
* There is a question about whether the Windows Git tools perform as well as the Hg tools {{devs}}
* IT team has limited experience with Git at this point {{IT}}
* git.m.o has had limited usage, need to review and stress test to ensure deployment can support scale {{IT}}
* Migration project is
===Requirements===
===Requirements===
* Update build tools (Windows tools specifically) to support Git
* Update build tools (Windows tools specifically) to support Git {{devs}}
** jlebar's tools https://github.com/jlebar/moz-git-tools
** jlebar's tools https://github.com/jlebar/moz-git-tools
* Must be able to create user repos as can do on Hg
* Must be able to create user repos as can do on Hg {{devs}}
* Pushlog equivalent needs to be created for Git {{devs}} {{releng}}
* Repository hooks {{releng}}
**tree closure
**approval required hook
**try syntax
* Update for Nightly about:buildconfig to link to Git revision {{releng}}
* Bugzilla must be updated to links to Git change sets, existing Hg links must not break {{devs}}
* tbpl.mozilla.org (links to changeset id) must be updated to support Git or an equivalent system put in place {{devs}} {{releng}}
* Will need to scale Git infrastructure (currently 2 machines) but should be able to reuse Hg machines {{IT}}


==Release Engineers==
==Release Engineers==
joduinn stated that releng has no issues with a move to Git, does have issues with a move to third party hosting of Mozilla repos
joduinn stated that releng has no issues with a move to Git, does have issues with a move to third party hosting of Mozilla repos
===Benefits===
===Benefits===
* Simplified debugging (no longer have to debug Hg)
 
* Simplified management as only one SCM system
===Issues===
===Issues===
* Security of repo on hosted provider
* Security of repo on hosted provider
Line 28: Line 45:
* Latency and failed pulls, some builds must pull from ~30 repos
* Latency and failed pulls, some builds must pull from ~30 repos
===Requirements===
===Requirements===
* Pushlog equivalent needs to be created for Git
* must have root access to repo to back out changes (have at Mozilla, don't have for Github repos) {{releng}}
* Repository hooks
**tree closure
**approval required hook
**try syntax
* Update for Nightly about:buildconfig to link to Git revision
* Bugzilla must be updated to links to Git change sets, existing Hg links must not break
* tbpl.mozilla.org (links to changeset id) must be updated to support Git or an equivalent system put in place
* must have root access to repo to back out changes (have at Mozilla, don't have for Github repos)
==IT System Admins==
==IT System Admins==
fox2mike stated that IT has no issue with a move to Git, does have issues with a move to third party hosting of Mozilla repos
fox2mike stated that IT has no issue with a move to Git, does have issues with a move to third party hosting of Mozilla repos
===Benefits===
* Simplified management of a single system
* Hg has required a lot of one off troubleshooting that consumes a lot of time, Git has required almost no troubleshooting thus far but may require more once scaled up
===Issues===
===Issues===
* Some teams (NSS, security) require internal hosting
* Some teams (NSS, security) require internal hosting
* IT team has limited experience with Git at this point
* IT team has limited experience with Git at this point
===Requirements===
===Requirements===
* Will need to scale Git infrastructure (currently 2 machines) but should be able to reuse Hg machines
* git.m.o has had limited usage, need to review and stress test to ensure deployment can support scale
Confirmed users
2,473

edits

Navigation menu