Skip to content

Git Migration

Jump to bottom
Yaswant Pradhan edited this page Nov 13, 2025 · 30 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

  • 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

  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) ☑️
      • There are some large files in the repository, consider Git-LFS
    • ❄️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) ☑️
      • Contact metomi owner to deprecate their repository.
    • ❄️svn:gcom/main (@trunk) → gcom (@main) ☑️
    • ❄️svn:jules/main (@trunk) → jules (@main) ☑️
      • Check licence agreements, if going public. (JULES in progress...)
      • Plan to migrate JULES documentation here. jules/pull/2
    • ❄️svn:socrates/main (@trunk) → socrates (@main) ☑️
    • ❄️svn:socrates/spectral (@trunk) → socrates-spectral (@main) ☑️
    • ❄️svn:utils/shumlib (@trunk) → shumlib (@main) ☑️
      • remove sensitive information
      • Update README (in progress...)
      • GitHub Actions to
        • Compile and run Tests
        • Generate API documentation
      • Contact metomi owner to deprecate their repository.
    • ❄️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 (in progress...)
    • LICENCE (in progress...)
    • CONTRIBUTING.md (CLA) (in progress...) Keep this in a central repository instead.
    • CODEOWNERS
    • CONTRIBUTORS
    • Correct Copyright statements, particularly in planned open-source repositories. (in progress...)
      • E.g., (C) Crown copyright, Met Office. All rights reserved. (post migration)
    • Automated Code Quality checks via GitHub Action (in progress...)
    • Migrate useful wiki pages from trac to GitHub (in progress...)
    • Map SRS to GitHub username, where possible. (Ref: Ben F.)

  4. Testbed

    • Create additional main branches (~rename trunk). (prior to 1st release on GitHub)
    • Test Fab (build tool) integration. (post migration)
    • Test Simulation System workflows with GitHub.
    • Make sure tags/releases are still functional.
    • Update Working practices. (in progress...)
    • Write branch migration guidelines
    • Allow limited number of developers to test their workflows.
    • Add/update Issue/PR Templates. (in progress...)

  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

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.

© Crown copyright, Met Office. All rights reserved.

Clone this wiki locally