947
edits
EngineeringProductivity/HowTo/MirrorRepo: Difference between revisions
Jump to navigation
Jump to search
EngineeringProductivity/HowTo/MirrorRepo (view source)
Revision as of 23:53, 18 July 2012
, 18 July 2012→Steps
(→Steps) |
(→Steps) |
||
| Line 8: | Line 8: | ||
This guide uses git [http://learn.github.com/p/tagging.html tags] which are simply a way to assign a name to a commit. This tutorial will use mozbase as an example, though the workflow can apply to any project. Now suppose you fix a critical bug, or add a major new feature that is needed by the test infrastructure in Mozilla-Central (herein called m-c). | This guide uses git [http://learn.github.com/p/tagging.html tags] which are simply a way to assign a name to a commit. This tutorial will use mozbase as an example, though the workflow can apply to any project. Now suppose you fix a critical bug, or add a major new feature that is needed by the test infrastructure in Mozilla-Central (herein called m-c). | ||
# Write your patch, attach it to your bug, get it reviewed, check it in to master and resolve the bug fixed as normal. Now it is time to mirror the latest master to m-c. | # Write your patch for mozbase, attach it to your bug, get it reviewed, check it in to master and resolve the bug fixed [https://wiki.mozilla.org/Auto-tools/Projects/MozBase#Working_on_MozBase_and_contributing_patches as normal]. Now it is time to mirror the latest master to m-c. | ||
# Create a new bug called "Mirror mozbase to m-c for xyz" or something like that and add your other bug as a depends on to make it clear why we are mirroring. | |||
# Copy the entire (up-to-date) mozbase folder from your git repository to the <i>testing/mozbase</i> directory in m-c. Alternatively you can use [http://k0s.org/mozilla/hg/fetch fetch] instead of copy and pasting. | # Copy the entire (up-to-date) mozbase folder from your git repository to the <i>testing/mozbase</i> directory in m-c. Alternatively you can use [http://k0s.org/mozilla/hg/fetch fetch] instead of copy and pasting. | ||
# (The annoying part) Go to https://github.com/mozilla/mozbase/compare/mozilla-central...HEAD and examine the commits listed there. These are all the commits in master that aren't yet in m-c (i.e this is what you are committing to m-c). Pay special attention for commits that add or remove files and make sure to 'hg add' or 'hg rm' those exact same files in your m-c repository. | # (The annoying part) Go to https://github.com/mozilla/mozbase/compare/mozilla-central...HEAD and examine the commits listed there. These are all the commits in master that aren't yet in m-c (i.e this is what you are committing to m-c). Pay special attention for commits that add or remove files and make sure to 'hg add' or 'hg rm' those exact same files in your m-c repository. | ||
# Test your changes to make sure you didn't break the build. | # Test your changes to make sure you didn't break the build using [https://wiki.mozilla.org/ReleaseEngineering/TryServer TryServer]. | ||
# Attach a diff of all the commits (including yours) that are going into m-c, get it reviewed, pushed to try and landed on mozilla-inbound. When mozilla-inbound is merged to m-c this bug can be marked fixed. Make sure your m-c commit message references the mozbase commit hash. | # Attach a diff of all the commits (including yours) that are going into m-c, get it reviewed, pushed to try and landed on mozilla-inbound. When mozilla-inbound is merged to m-c this bug can be marked fixed. Make sure your m-c commit message references the mozbase commit hash. | ||
# Create a git tag called 'mozilla-central' on your commit, you'll need to delete the old 'mozilla-central' tag. This way, the changeset tagged 'mozilla-central' will always keep track of the current state of mozbase in m-c: | # Create a git tag called 'mozilla-central' on your commit, you'll need to delete the old 'mozilla-central' tag. This way, the changeset tagged 'mozilla-central' will always keep track of the current state of mozbase in m-c: | ||