💬 SVN/Trac to Git/GitHub Migration: Share Your Experience!

[Yaswant Pradhan (yaswant)]

Hi everyone,

Since our move from SVN and Trac in early 2026, we’ve successfully completed our first release using Git and GitHub. With the next release coming up in a month, we’d like to hear how the new workflow is working for you.

Some team members have already given positive feedback about the improvements. To help us improve our process for the next release and plan any needed support, please vote in the poll below and share your comments.

💡 Things to consider in the comments:

• What is working much better for you than Trac/SVN?
• Is anything currently slowing you down or causing friction?
• Are there any Git concepts or GitHub features you'd like a quick training session on?

Thank you for helping us make our development process better!

This poll is completely anonymous

[David Thomson (DavidJohnThomson)]

I really like that git is a more standard tool outside the Met Office (relative to fcm). That makes collaboration easier. But I also really miss the "revision log" functionality of trac. Github has something similar for their wiki pages but not for the code, at least not in a form that is so straightforward and easy to use.

[Yaswant Pradhan (yaswant)]

Hi David Thomson (@DavidJohnThomson)

Thanks for the feedback! It is great to hear that switching to Git is already making external collaboration easier for you.Regarding the revision log functionality from Trac, GitHub actually has built-in features that do exactly this for code, though they are located in different places than Trac. You can view a full, chronological revision log of the entire project by clicking the Commits tab (the clock icon) on the main repository page. If you want to see the revision history of a specific file, just open that file in GitHub and click the History button at the top right.

Hope that helps. If you have further questions please feel free to drop in one of the Git and GitHub surgeries.

[David Thomson (DavidJohnThomson)]

Thanks. I wasn't aware of that but was aware of the "activity" page which is similar. However I think (hopefully wrongly) that it doesn't enable me to do what I want. With trac if I want to compare two revisions I just click the "radio buttons" for the two commits that I want to compare. Then, if I've selected the wrong two (or am doing a bisection search through the history), I can easily amend the radio buttons and see the updated differences. In github I have to copy the commit references into a compare page and then, if I want to e.g. look one commit earlier, I go back to the list of commits and then - oh dear - I can't remember which one I copied! If I can remember, I select a new candidate but, when I go to the compare page, I can't remember if I want to post it on the left or right. So I can do what I need to if I work carefully and make notes, but something which might take 2 mins in trac can take 2 hours and is rather tedious (requiring breaks for tea!). It probably wouldn't be difficult to add the radio buttons - could we try to persuade them to add this option? Using blame does sometimes help a bit but is not really a good substitute for the radio buttons.

[Yaswant Pradhan (yaswant)]

I totally understand your frustration -- GitHub's web UI is actually terrible for chronological bisection compared to Trac. GitHub assumes everything happens in a Pull Request, so comparing two random points in time is buried. For someone used to Trac’s linear SVN timeline where you can casually compare revisions, e.g. r100 to r120, with two clicks, GitHub feels incredibly clunky.

I am not very optimistic about persuading GitHub to change their core UI😔. Browser extension such as refined-github claims to add checkbox/radio buttons next to every commit, but getting that approved will require a formal software request via SN.

However, there are few tricks and tools you can use right now to drastically speed up your workflow without needing any software approval. The core rule to remember is: Old on the Left, New on the Right.

Browser based URL trick

Instead of going back and forth between screes, if you bookmark the repository's native comparison URL structure, e.g. https://github.com/MetOffice/simulation-systems/compare/ and edit the URL directly like old-sha...new-sha in the address bar.

To save you from copying and pasting long commit hashes, you can use relative modifiers directly in the URL bar:

Shortcut	Meaning	Example
HEAD	Exactly where you are standing right now	compare/main...HEAD
main	The very tip of the main branch. Can also use tags or SHAs	compare/vn3.0...main
vn3.0	The exact state of the repository at tag vn3.0	compare/vn3.0~5...vn3.0
~1	One commit before this point	main~1 (second most recent commit on main)
~5	Five commits before this point, and so on..	vn3.0~5 (Five commits older than tag vn3.0)

If you are on a comparison page and want to shift your search one commit earlier, just click the URL bar, append ~1 to the hash or tag, and hit Enter. The page updates instantly.

Using GitLens in VS Code

If you use VS Code, the GitLens extension completely eliminates the need to use the GitHub website for history tracking. It brings a powerful, interactive timeline directly into your editor that perfectly replicates the Trac workflow.

1. Open the Commit Graph: Open the Source Control tab on the left sidebar and click on the Commit Graph icon at the top. This opens a linear, visual timeline of your repository.
2. Trac "Radio Button" Equivalent: Find your first commit in the graph list. Hold down the Ctrl key and click your second commit.
3. Compare: Right-click either of the highlighted commits and select Compare Commits.... A dedicated side panel will instantly open, showing you every modified file and the exact line-by-line diff between those two points.
4. Seamlessly Shifting History: If you realise you picked the wrong commit, just keep your comparison panel open and click any other commit in the visual graph. GitLens will instantly update your view, letting you step backwards or forwards with a single click.

Command-line

If you want to bypass the browser entirely, you can run a diff straight from your terminal.

# Compare two points in time
git diff <OLD>..<NEW>

# See what changed in a single file
git diff <OLD>..<NEW> -- path/to/file

If you prefer a visual side-by-side comparison over terminal text, you can configure¹ Git to open the changes in a graphical UI (like meld or xxdiff) by using difftool instead of diff:

git difftool <OLD>..<NEW> -- path/to/file

Footnotes

1. Run these three configuration commands once in your terminal to set it up globally:

   # 1. Define meld as the default tool for diffs
   git config --global diff.tool meld
   
   # 2. Disable the annoying prompt asking "Launch meld?" for every single file
   git config --global difftool.prompt false
   

   ↩

[David Thomson (DavidJohnThomson)]

Many thanks - lots to explore there. Refined-github looks interesting but it adds a large number of things and I'd be a bit wary about that unless it was widely used across the Office. I couldn't immediately see the commit radio buttons in the readme - if you know where it mentions the radio buttons that would be good. Getting more fluent with VS Code and exploring gitLens is probably what I need to do (hopefully it's less cryptic than gitk).

[Wolfgang Hayek (tinyendian)]

I like the new git workflow a lot, it's much easier than the old TRAC/svn/fcm workflow. I does sometimes seem a bit more difficult to get reviewers' attention for outstanding PRs, this seemed easier for TRAC tickets. Could simply be that everyone's busy at the moment, though.

[Yaswant Pradhan (yaswant)]

Thanks for the feedback, Wolfgang Hayek (@tinyendian)!

It is great to hear that you are enjoying the new Git workflow and find it easier compared our old SVN/Trac setup.

You raise a valid point about the visibility of outstanding PRs. Switching tools does change how we track our work, and it takes some time for everyone to adapt their notification habits.

To help keep things moving efficiently, here is a quick reminder (for everyone) of our agreed working practices for PR reviews:

• Find your SciTech Reviewer: Authors are responsible for identifying and inviting their own SciTech Reviewer (SR) to the PR.
• Code Reviewer assignment: Once your SR is sorted, SSD team will officially assign the Code Reviewer (CR).
• Check the status: Ensure your PR is out of Draft mode, as reviewers will skip drafts.
• Watch the milestones: If your PR has a milestone, both the SR and CR must be completed before the listed CR deadline.

If your PR is still stuck, please feel free to gently nudge your reviewer(s) directly or drop a reminder to the SSD team.

[Wolfgang Hayek (tinyendian)]

Thanks Yaswant Pradhan (@yaswant). Finding a SciTech reviewer can sometimes be a bit difficult - it's now always clear for external partners who knows the code well enough, and code owners don't always take on SR or suggest a reviewer. That was already the case in the old TRAC/svn world, though; help from the SSD team is always highly appreciated!

[Yaswant Pradhan (yaswant)]

I totally understand that. Finding the right SciTech reviewer has been a historical bottleneck since the Trac/SVN days, especially when code ownership is ambiguous or owners are stretched too thin. The SSD team is always happy to step in and facilitate; feel free to tag us on any PRs or tickets where the reviewer path is unclear.

[Denis Sergeev (dennissergeev)]

I also like the Git/GitHub workflow a lot more than SVN/Trac.

As a collaborator from academia, this definitely streamlines the process and helps include more external collaborators, including students. For students in particular, getting involved in developing MO codebases here becomes a key way to learn Git/GitHub and get a taste of working on a massive collaborative software project.

There is of course a bit of a learning curve for people used to SVN/Trac but hopefully this is just a matter of time.

[David Thomson (DavidJohnThomson)]

Is it easy to see in github when a branch diverged from main? On a PR you can see the dates of the commits but not I think the date that the branch was created. This was straightforward on trac because the branch creation involved a commit. Probably there's a simple way to see this but I haven't found it.

[David Thomson (DavidJohnThomson)]

I'm fairly sure that's not correct. E.g. if on the pr's "files changed" page you just select a single commit which is a merge from main, then it will say (in the cases I've tried) "No changes to show". Also if you look at changes from all commits, then you don't see changes due to merges from main (in the sense that they are not marked as changes - the text does of course reflect the merges from main).

[Yaswant Pradhan (yaswant)]

I think, both of you are correct. While James Frost (@jfrost-mo)'s views are purely Git-centric, David Thomson (@DavidJohnThomson) is exactly right about the GitHub UI behaviour - the tricky bit you noticed is a result of how GitHub translates Git commands into its interface.

James is thinking of a standard two-dot comparison (git diff A..B), which strictly calculates the mathematical delta between two snapshots. I think, if GitHub did this, any code merged from main into the PR during that range would flood the files changed view.
GitHub builds its PR view using a three-dot diff logic (git diff base...head) - see Three-dot and two-dot Git diff comparisons.

When looking at a sub-range or a single merge commit:

1. Standard merge commit: GitHub looks at the merge commit's two parents. Because the code coming from main (parent 2) is already part of the base branch history, GitHub filters it out, resulting in "No changes to show".
2. "Some changes" edge case: If the range includes a merge commit where merge conflicts were manually resolved, those edits are unique to the PR branch. GitHub cannot filter those out, so the diff will display those specific conflict resolutions (and occasionally nearby context lines).

[James Frost (jfrost-mo)]

Thanks for the clear description, I've never before been clear on the difference between .. and ... ranges.

[David Thomson (DavidJohnThomson)]

Thanks. My understanding was that 3 dots showed changes in right hand branch relative to common ancestor and your link above says its "the difference between the latest common commit of both branches (merge base) and the most recent version of the topic branch". I think these mean the same thing. But I think it's quite hard to interpret that as implying what is seen on github. E.g. if select a range that includes all the commits on the branch then it's hard to argue that versions of main merged in are the latest commit common to the beginning and end of the range (they are not in the beginning of the range). So probably the extra complexity is to do with what branches the difference is between. I think sometimes it's between the branch and main and sometimes (if the range starts some way between two merges of main), it's between the branch and itself at the two ends of the range. That still doesn't explain the suppression of some changes though in the second case.

I think these things do matter for getting QA right. E.g. I'm currently trying to review a branch with 126 commits and quite a few merges of main and it's proving quite hard! It's difficult to review all the changes together and easier to consider individual commits as they consider different aspects of the problem. But then one does need to worry about how they are combined, conflicts in merges, and exactly what github is showing when looking at a subrange of commits. But perhaps the lesson is that it's better not to have such large commits (which would have been hard in fcm too, even though trac would have been easier to understand conceptually).

[David Thomson (DavidJohnThomson)]

I've got an interesting example of a PR illustrating problems with github's choice of what it shows on the "files changed" tab in PR's. There is a merge of main into the "branch" and if I look at this commit in GitHub (i.e. via the commit page - not via the "files changed" tab on the PR) I can understand what is happening. If I select "hide white space" there are 2 lines added and 1 line changed. If I don't hide white space, there are "+385 -383" lines changed. These arise partly from white space changes (adjusting indentations) but also because the git comparison gets "out of alignment" and compares the wrong lines. Although it's hard work one can go through these changes and see that very little has really changed.

However if one looks at the pr's "files changed" tab for the commit in question it is very misleading. It (I think) suppresses some of the changes and shows "+24 -206" lines changed. So it appears to show that large amounts of code have been deleted and it looks like the code has been badly corrupted. I should say that this is not the first time I've seen this sort of problem. Selecting "hide white space" here doesn't help (it still shows +24 -206).

Rebasing instead of merging would avoid this problem for reviewers, but would make it harder work for pr developers. Adopting the fcm method of taking a branch from the head of the trunk and merging the old branch in (which is a bit like rebasing but with the intermediate commits lost) would also help (but with the disadvantage of losing the intermediate commits). Perhaps the best approach is just to never trust what the pr's "files changed" tab shows for a merge (considered in isolation) without checking the commit.

[Alan J Hewitt (alanjhewitt)]

We spoke offline about this, but for the most part I think it is an improvement over fcm, especially the ease of being able to upgrade to main (its going to take a while not saying head of trunk). I have probably a hundred hours previously updating fcm branches to HoT, so the ability to do it now with a button press is really great.

Reviewing has been streamlined, which is probably a good thing, although it might be good to have kept some friction in the process to stop approvals happening on autopilot.

The only noticeable disadvantage is the same one that David Thompson mentioned, that visualising differences between revisions in github is not as easy as it it was when using trac. I will probably skill up enough with github for this to be a minor inconvenience in the future. I want to see differences in the browser on one screen whilst having the code on the vdi on the other screen