Skip to content

Git Migration

Jump to bottom
Yaswant Pradhan edited this page Dec 16, 2025 · 36 revisions

Simulation Systems Git Migration

This project is aimed to migrate the Met Office simulation systems repositories to Git ecosystem. See announcements 394, and 337 for details.

Simulation Systems Git Migration – Upcoming Changes and Timeline - 2

Note

Pre-requisites to run the migration script (for admins)

  • Read access to the Met Office Science Repository MOSRS or the Met Office internal mirror (svn://fcm1 https://metomi/svn).
  • Optional Write access to the Met Office GitHub organisation for push to remote (usually, an admin).
  • Tools: fcm, git, gitlify, jq, and gh available on the system.

Checklist

Keys:

❄️SRS trunk Frozen permanently; ☑️ SRS Trunk and release tags fully migrated to Met Office GitHub; ✅ Section completed

  1. ✅ Test gitlify translation tool

    • Able to convert only svn trunk to Git.
    • Able to map svn revisions to Git tag.
    • Synchronise trunk updates locally in Git repositories.
      • Set-up a (scron) job to update code/tags routinely.

  2. ✅ Create/update GitHub repositories under MetOffice

    • ❄️svn:um/main (@trunk) → um (@main) ☑️
    • ❄️svn:um/aux (@trunk) → um_aux (@main) ☑️
    • ❄️svn:um/meta (@trunk) → um_meta (@main) ☑️
    • ❄️svn:um/doc (@trunk) → um_doc (@main) ☑️
      • Compress/convert large graphics in the repository consulting the authors/IAO.
      • Implement GitHub Action to build/deploy docs: um_doc/pull/2
    • ❄️svn:um/mule (@trunk) → mule (@main) ☑️
    • ❄️svn:gcom/main (@trunk) → gcom (@main) ☑️
    • ❄️svn:jules/main (@trunk) → jules (@main) ☑️
    • ❄️svn:socrates/main (@trunk) → socrates (@main) ☑️
    • ❄️svn:socrates/spectral (@trunk) → socrates-spectral (@main) ☑️
    • ❄️svn:utils/shumlib (@trunk) → shumlib (@main) ☑️
      • remove sensitive information
      • Update README
      • GitHub Actions to
        • Compile and run Tests
        • Generate API documentation
    • ❄️svn:ukca/main (@trunk) → ukca (@main) ☑️
    • ❄️svn:monc/casim (@trunk) → casim (@main) ☑️
    • ❄️svn:moci/main (@trunk) → moci (@trunk) ☑️
    • ❄️svn:lfric/LFRic (@trunk) → lfric_core (@trunk) ☑️
      • Repository already exists: ask for admin access to the repository.
    • ❄️svn:lfric/GPL-utilities (@trunk) → rose_picker (@trunk) ☑️
    • ❄️svn:lfric_apps/main (@trunk) → lfric_apps (@trunk) ☑️
    • ❄️svn:monc/main (@trunk) → monc (@trunk) ☑️
    • Check config.json is correct and up-to-date with MOSRS revisions.

  3. ✅ General updates for all repositories (during migration)

    • All private with specific team access only.
    • Repository Description.
    • README.md
    • LICENCE
    • Contributor Licence Agreement (CLA) checks (Momentum-CA from MetOffice/Momentum).
    • CONTRIBUTORS.md
    • Correct Copyright statements, particularly in planned open-source repositories.
      • E.g., (C) Crown copyright, Met Office. All rights reserved. (post migration)
    • Map SRS to GitHub username, where possible. (Ref: Ben F.)
    • Add/update Issue/PR Templates.

  4. ✅ Testbed

    • Create additional main branches (~rename trunk). (prior to 1st release on GitHub)
    • Test Simulation System workflows with GitHub.
    • Make sure tags/releases are still functional.
    • Update Working practices.
      • Write branch migration guidelines.
    • Partner testing -- Allow limited number of developers to test their workflows.

  5. ✅ During SRS freeze

    • Test trunk and main are able to merge with different history.
    • Merge trunk in future default (main) and delete trunk

  6. ✅ Update communication plan

  7. Post Migration

    • Automated Code Quality checks via GitHub Action (in progress...)
    • Migrate useful wiki pages from trac to GitHub (in progress...)
    • Test Fab (build tool) integration.
    • Review Crown copyright statements on all Momentum® codebase.
    • Consider Git-LFS for large files in the um_aux repository.
    • Contact metomi owner to deprecate their repository.
    • Contact metomi owner to deprecate their repository.
    • CODEOWNERS in all repos? (tbc)

FAQ

How long it takes to convert svn repo to Git? The listing below shows the time taken to convert trunk-only branches and attach svn tags to the Git repository locally using ssd_svn2git.sh script. 
$ tail -n1 *.log
==> 20250330T025505_casim.log <==
2025-03-30 02:56:25 Done: casim in 00:01:20

==> 20250330T025625_moci.log <==
2025-03-30 02:59:42 Done: moci in 00:03:17

==> 20250330T025942_jules.log <==
2025-03-30 03:14:50 Done: jules in 00:15:08

==> 20250330T031450_socrates.log <==
2025-03-30 03:17:04 Done: socrates in 00:02:14

==> 20250330T031704_ukca.log <==
2025-03-30 03:18:06 Done: ukca in 00:01:02

==> 20250330T031806_shumlib.log <==
2025-03-30 03:19:40 Done: shumlib in 00:01:34

==> 20250330T031940_mule.log <==
2025-03-30 03:24:19 Done: mule in 00:04:39

==> 20250330T032419_um_aux.log <==
2025-03-30 03:29:52 Done: um_aux in 00:05:33

==> 20250330T032952_um_doc.log <==
2025-03-30 03:42:31 Done: um_doc in 00:12:39

==> 20250330T034231_um_meta.log <==
2025-03-30 03:46:47 Done: um_meta in 00:04:16

==> 20250330T034647_um.log <==
2025-03-30 05:04:04 Done: um in 01:17:17

==> 20250330T050404_gcom.log <==
2025-03-30 05:06:17 Done: gcom in 00:02:13

==> 20250330T050617_lfric_apps.log <==
2025-03-30 05:11:44 Done: lfric_apps in 00:05:27

==> 20250330T051145_lfric_core.log <==
2025-03-30 05:48:32 Done: lfric_core in 00:36:48
What happens to a tag if the corresponding branch gets deleted? A branch is simply a way to track a collection of commits. The tag and commit would stull exist if the branch is deleted. Ref: community/discussions/23918.
When will the developers get access to the GitHub repositories Please refer to the timeline in Simulation Systems Discussion. We will announce the opportunity to participate during the later part of migration testbed.
My forked repository got detached from upstream repository following a visibility change (private to public) upstream

The "detached" state is a security feature to isolate private forks when the upstream parent becomes public. Only GitHub staff have the administrative privileges required to manually re-link the repository network while preserving existing PR data and history.

One option is to recreate the fork from upstream and manually add branches. However, if you already have a lots of develop branches/PRs, its probably best to contact GitHub Support and Submit a ticket to reattach your fork with upstream with the following message:

My upstream private repo became public, which detached my fork. I have open PRs I need to preserve. Please reattach my fork to the original network.

Upstream URL: https://github.com/MetOffice/{repo-name}
Fork URL: https://github.com/{user}/{repo-name}

This process should usually get resolved within a day.

© Crown copyright, Met Office. All rights reserved.

Clone this wiki locally