DEV Community: Sasha Medvedovsky

The compounding effect of version control performance

Sasha Medvedovsky — Thu, 11 Sep 2025 14:18:20 +0000

By: Pablo Santos Luaces

As software developers we tend to focus on the latest, shiniest new feature and often take for granted the core value of our product.

I remember the surprise when visiting a customer and asking their team what they liked better about the product: every morning it syncs much faster than the previous version control. It wasn’t the latest change in the UI, the super advanced merge feature we just added. It was the speed. I took it for granted. I considered it something that of course was important but that has been there for years. And it was the real key thing.

And something often overlooked about speed is how it compounds and impacts productivity in ways that are initially not considered.

‍

Diversion performance boost

During the last few months the team at Diversion has dramatically improved the speed of the product. They swarmed together to respond to the requirements of much larger customers. When you have to handle millions and millions of files in the head of the repo, the rivets start to pop.

To some extent, these teams need some performance to just operate. But in Diversion they have not only matched but vastly outperformed the version control they are replacing. And this creates new opportunities.

‍

The compounding effect of speed

An improvement in the speed of your daily version control operations, sync or submit, for instance, makes you wait less.

Every operation that takes more than just a few seconds makes you switch context, go to X or Insta or whatever, then ruin your flow.

So, if an operation goes down from, let’s say, 30 seconds to 10, the impact is not only 20 seconds times the number of operations per day, it is much more. The threshold between less than 10 seconds and more than 20 provokes minutes of time wasted browsing the internet, going to Slack to chat while you wait, etc.

But there is more: when an operation is not painfully slow, it creates new opportunities that go beyond saving time and into real workflow changes.

‍

Fast branching changes the game

Take the branching example. One of the most used version control systems in the gaming industry can’t branch in a performant way as soon as the depots grow too large. Taking 5-20 minutes to create a branch makes it an event, something to be planned, considered, feared. It is not something you do lightly. And then entire workflows are shaped around that limitation (which is something very, very common in the gaming industry).

Now, suddenly your branching time goes from 5 minutes to 20 ms like it happens with Diversion. The naïve way to think about it is: ok, we create 1 branch a month, so we’re only saving 5 minutes a month, it is definitely not worth the change.

Obviously the impact is way different: suddenly the team can create as many branches as they want. If you want to work on a new ticket, you can go and create a branch for it, lightly, no planning, no approvals, because branches suddenly become an instrument of productivity, not a release event. You can use branches to develop tasks and they can be timely merged, but the review process will be driven by the branch (something Git users take for granted but many game teams do not because Git can’t handle the sizes of their binaries fluently).

Same can happen with release branches, experiment branches, ideas, etc. Fast branching opens up improvements that go beyond the current workflow.

‍

Art and code in a single repo erases artificial complexity

And branching is just one example, but the same happens with the ability to handle code and art, no matter the size, in the same repo. Do you simply accept the extra complexity of dealing with code in one repo and art in a second one because the system that manages code is not good with big assets, and the one that deals with large binaries doesn’t offer the features programmers demand?

‍

Wrapping up

Like a friend of mine always says for their data analytics platform: speed matters. It matters a lot. It does not just remove blockers, it creates whole new opportunities when you can suddenly perform operations that you accepted to be costly in almost no time.

‍

About the Author

Pablo Santos Luaces is the founder and former CTO of Plastic SCM, SemanticMerge, and Gmaster. An accomplished programmer specializing in version control and merge technologies, he now shares his insights on these topics through writing and speaking, including on his Medium page.

The Agile, The Fragile, And The Iron Fist Of Branching Strategies

Sasha Medvedovsky — Wed, 19 Jul 2023 07:08:58 +0000

Whether you love it or hate it, Git has proven to be the nearly ubiquitous method engineering organizations employ to ship code today. However, when you’re just getting started and building your team, you may be thinking about which strategy is the right one for you to choose based on your current and future needs.

‍

We recently wrote a longer post about effective branching strategies, and the considerations involved when selecting your branching strategy of choice. However, we still believe it could be useful to dive in more deeply into the underlying philosophy for each branching strategy, to help you decide what code shipping strategy is the right one for your engineering team.

‍To make a very rough generalization, we can largely split branching strategies into those that are more agile in nature and those that are more structured. Each is employed to provide either more rapid delivery or greater control, if we were to think about them in a very generic way. Below we’ll dive into the most common strategies, from the structured to the agile, their benefits and what they’re best suited for. Hopefully this will help make the decisions regarding what can work best for you and your teams, and whether you need to rethink your branching strategy altogether.

‍

Structured Strategies

‍

Release Branching

‍This strategy is well-suited for large teams and projects that require long-term support for multiple versions. It’s no surprise then that both Microsoft and the Apache Software Foundation often employ release branching as their strategy of choice. (For those who aren’t familiar, the Apache Software Foundation is best known for hosting numerous open-source projects. The way they work is: each major release has a dedicated branch where bug fixes and patches are applied while development continues on separate branches).

TL;DR:

In this strategy, a separate branch is created for each major release version, where bug fixes and patches are applied to the release branch.
New features are developed in separate branches. ‍

When to Use It

Release branching is best suited for projects that require stable release maintenance while continuing development on other branches. This is because it offers a controlled and structured approach to managing releases, along with greater stability. Another situation where this strategy is used is in large projects with frequent releases (e.g. games) - the release branches isolate features scheduled for the upcoming release from ones that are not.

‍Advantages: The release branching strategy’s greatest advantage is that it provides strong isolation between releases, allowing clarity in multiple versions support, and scheduling and coordination of release cycles in large scale projects.

‍Disadvantages: This strategy creates numerous long lived branches, which complicates code management - it creates a need for complex merges to make sure code written in one branch (e.g., a bug fix) propagates into the other branches correctly. Use this strategy only where needed.

‍

GitFlow

GitFlow is a variation on the release branching strategy, that also defines additional long lived branches for different purposes. It was conceived in 2010 by Vincent Driessen.

TL;DR:
It consists of a "develop" branch for ongoing development and a "master" branch for stable releases (we’ll call it ‘main’ from this point on to align with the more modern terminology).
Additional branches are used for feature development, bug fixing, and release preparation. These branches are deleted once they are merged to “develop” and “main”.
‍
The Way it Works
Gitflow uses a central repository approach with two long lived branches: 'main' for production and 'develop' for integrating features. Additional temporary branches are created for isolating new feature developments and for preparing production releases. After a feature is developed on a feature branch, it's merged into the 'develop' branch.

‍When a release is ready, a release branch is created off 'develop', which is then merged into the 'main' and 'develop' branches, when the release is complete.
‍
When To Use It
GitFlow was commonly used (and still is, in some places) in projects with a scheduled release cycle. Teams working on software that has major scheduled releases, like operating system distributions, often use this strategy to add greater control and stability to the project.

Advantages: Clear separation of under-development code and production; streamlined release management.

Disadvantages: Bad fit for CI/CD processes; a complex workflow with multiple branch types and merging strategies.

‍

The Agile Strategies

Feature Branching

‍

‍Feature branching enables parallel development, isolation, and collaboration among developers. It places the emphasis on agility, collaboration, and shorter feedback loops, which is why it is one of the more popular branching strategies employed with many development teams, including well-known engineering organizations like Atlassian.

‍

TL;DR:

In the Feature Branching Workflow, developers create a branch for each new feature.
The 'main' branch contains the official project history, and feature branches are used to develop new features outside of the main project.
When a feature is complete, it's merged back into the main branch.
Different instances of this flow are known as ‘Github Flow’ where code is pushed to production upon its merge and ‘Gitlab Flow’ which schedules code for release across one or more staging branches. ‍

When To Use It

Due to its flexibility this strategy is suitable for teams of all sizes, although it should be noted that it can become complex for larger teams if branch management is not done properly. This is oftentimes the go-to strategy of choice for those who want both agility with some semblance of control and isolation.
‍
Advantages: This strategy is great for collaboration as each feature branch allows developers to work on new features without disturbing or impacting the main branch, which is kept production ready. Yet on the collaboration side, changes can be shared and discussed before being merged into the main code base.

‍Disadvantages: Probably its biggest downside is that it can lead to "merge hell" if not managed properly. This tends to happen when many branches are created and worked on concurrently, making the merging process a complicated and time-consuming task.

‍

Trunk-Based Development

‍

Trunk-Based Development allows agility, large-scale collaboration and fast-paced development. This strategy is common in organizations that practice continuous integration and deployment, and is used in conjunction with feature flags (with tools like LaunchDarkly). It is often used by large consumer-facing companies such as Google, Meta and Netflix.

‍

TL;DR:

Trunk-Based Development is a branching strategy where all developers work on a single branch, usually the main branch or "trunk."
Short-lived feature branches are created, but they're merged into 'main' as soon as possible - usually before the developed feature is complete.
Continuous integration tests are run to ensure 'main' is always in a releasable state.
Feature flags or toggles are used to enable or disable unfinished or experimental features. ‍

When To Use It

This strategy is useful in organizations that prioritize continuous integration and deployment, over isolation or control. While enabling velocity, this does require discipline to keep the main branch always in a releasable state so that unstable code is not inadvertently pushed to production. In large companies like Meta and Google, this is the only viable strategy - as any branch that splits off main falls hopelessly behind extremely quickly, making merging back an impossible task.

‍

Advantages: This strategy encourages regular code integration, decreases the complexity of merging changes, and supports continuous integration and deployment practices.

Disadvantages: The constant integration can lead to problems if not done carefully. This format requires strong release engineering to support it, and additional feature flags / toggles tooling to ensure experimental and unfinished features aren’t released at large without proper controls.

‍

While it may appear that the more “agile” approaches have similar principles, they prioritize different aspects of the engineering workflow. The Feature Branch workflow allows more flexibility in terms of when deployments happen; Trunk-Based Development emphasizes regular code integration and continuous delivery.

‍

How to Choose Your Strategy

Some of the key factors to consider when selecting or changing the branch strategy for your engineering organization are:

Release frequency
Risk tolerance
Project complexity
Team size

Regardless of the strategy you employ, the version control system you choose should provide the following:

Fast branching and updates
Flexibility
Ease of resolving conflicts
Real-time collaboration

The next generation of cloud native version control systems should focus on all of these elements to ensure that modern engineering can deliver fast and stay safe. There is also a need for better automation of processes like merges and conflict resolution; these may be greatly improved in the near-term by leveraging new generative AI tools, which promise to free us from mundane and frustrating tasks - but this deserves a separate post.

Version Control for Game Devs: Survey Results

Sasha Medvedovsky — Tue, 24 Jan 2023 15:10:51 +0000

Yuki Arbel, January 24, 2023

"Listening to your customers is the key to building great products"

Anonymous

At Diversion, we are building a next generation Version Control tool, with a strong emphasis on addressing the unique challenges faced by game developers. It’s no secret that the games industry is underserved by existing solutions (see here), but we wanted to hear first hand from game developers about the tools they are using, how they use them, and what challenges they encounter.

With that in mind, we ran a survey among professional game developers. Obviously, people are busy, and you need to show your gratitude for their willingness to contribute, so we added a raffle for VR goggles. We ended up with more than a 100 respondents before closing the poll.

‍

Who responded to our survey?

We asked people what size of organization they are currently working for. We thought this could be important in order to look at usage patterns and challenges also from that angle. It is one thing to be an indie developer or work with handful of colleagues, and another to work in a large enterprise split across continents. 45% of our respondents work in small companies (up to 100 employees), 40% work in midsize companies (up to 1000 employees), 15% work in large companies (larger than 1000 employees). We’ll get to some analysis using this information later on.

‍‍

So, which version control tools are game developers currently using?

Our main goal was to find out the distribution of version control tools among game developers.

Git is by far the most common version control solution reported by game devs (used by 82% of respondents). However, approximately 25% of those who use Git also use another version control tool in addition to it.

Other version control products used by survey participants:

Perforce (28% of respondents)
SVN (6% of respondents)
Plastic SCM (4% of respondents)

There were also 2 respondents reporting using an internally built version control system (which might indicate a lack of adequate solutions, and is probably less than ideal for a game development company).

Differences by company size

We looked further into the tools usage patterns, to see if they depended on organization size. Perforce is much more common in larger companies than in the smaller ones. More than 38% of respondents working for mid to large companies (companies larger than 100 employees) use Perforce, compared to 11% in smaller companies (under 100 employees).

Graphical assets

Binary files, and especially graphical assets, are a huge problem (pun not intended) in game development. We wanted to check how game developers deal with this problem.

First, we wanted to check whether designers use version control to store the assets that they create. It turned out that nearly half of respondents (45%) say that designers in their company use cloud storage to store the assets that they create. We assume that part of the reason is the complexity of using version control (which we were able to correlate from other responses they provided), as well as large storage volume required to store versioned assets (as version control products don’t have a way to manage that).

‍

Then, we wanted to check how common it is to keep graphical assets in version control (at least the end result of artists’ work). 78% of respondents who use Git and were familiar with the topic reported that graphical assets are also versioned. We’ve got a few more detailed responses explaining that only the final assets are versioned, which makes us believe this may be a typical scenario.

‍
Since large files don’t work well in Git, we wanted to cross correlate this with the use of Git LFS. 59% of Git users reported they are also using Git LFS to handle large files (some of them reported about problems with it, but this deserves a separate article).

From direct interviews we know that some companies who use Git to version code, are also using SVN or Perforce in conjunction with Git to store large assets. This of course is not optimal, as it complicates the toolchain and reduces the team’s ability to collaborate effectively. This might explain the high percentage of cross-usage between Git and SVN/Perforce.

‍

Hosting

While the global trend is to move hosting to the cloud via SaaS, all prominent Git vendors also offer their product as software that can be installed and maintained by the customer himself. We wanted to understand to what extent this trend is applicable to game developers. First, we wanted to learn how many of our respondents consume their remote Git as a cloud service vs. install the software on-prem. Approximately 22% of our respondents were not sure about this, but from those who did know where their Git is hosted, approximately 2/3 are using the cloud, and 1/3 are hosting Git on prem.

‍

Next, we wanted to understand the split between the different Git offerings in the market. The majority of companies are using Github (41%), followed by Gitlab (30%) and Bitbucket (22%).

‍

Challenges

Finally, we wanted to explicitly ask about challenges. After all, we are building Diversion in order to better address existing challenges with version control products, so we’d better know what they are.

Many respondents that use git reported on challenges they are having with the solution. Here are the top 3:

38% of respondents who use git indicated it is too complex for use by non-developers
25% of respondents who use git indicated it has poor support for graphical assets
21% of respondents who use git indicated it is slow ‍

We also asked about challenges with Perforce. One of the challenges that was highlighted by users for Perforce was complexity of use by non-developers (seems to be a common theme). Another challenge that stood out in the responses was a poor branching experience.

Finally, we asked about the existence of a dedicated team handling the version control tool. While this does not necessarily translate to a challenge for the end users, it does impose costs and an operational burden on the organizations. To this question, 64% of respondents who were familiar with the subject, indicated that such a team exists in their organization.

‍

File conflicts

One common challenge that we haven’t included in the survey, but that has surfaced in interviews we conducted, is file conflicts. One company we talked about told us they have a slack channel where artists ask each other if someone’s working on a specific art file (of course, sometime this workflow fails). Others have reported frequent and impossible to solve merge conflicts in Unity or Unreal Engine’s files (scene files, prefabs, etc.). Some version control tools offer an ability to lock files (not Git); but this introduces other problems (people forgetting to unlock files). None of the companies we’ve talked to uses file locking - clearly, a better solution is needed.

‍

What’s next?

As we can see, version control remains a significant challenge in game development. The most probable reason is that the popular version control tools were not built with game development in mind, or are just very old and were not built for today’s scale.

We continue to work hard to get Diversion to you. It’s currently in private beta to our early subscribers, and we plan a wider release in the coming weeks. Stay tuned!

On Git and Cognitive Load

Sasha Medvedovsky — Thu, 24 Mar 2022 14:49:53 +0000

Any developer working in a modern engineering organization is likely working in git. Git, written by Linus Torvalds in 2005, has been since its creation, basically the ubiquitous tool for source control management. Git gained widespread adoption across engineering organizations as the successor to existing source control management such as Apache Subversion (SVN) and CVS (Concurrent Versions System), and this was mostly a byproduct of the timing.

Git predates cloud and improved network connectivity, and therefore the best solution to managing source control at scale, was to decentralize and leverage local dev environments to power engineering organizations. Fast forward 17 years, this is no longer the case. Cloud is de facto, networking and internet connectivity is blazing fast, and this changes everything.

Git itself as a system, while it has its benefits, is known to come with a lot of complexity that ultimately translates to cognitive load for developers. This post is going to dive into that a bit, and how we can improve upon previous source control systems to deliver improved developer happiness in the future.

The Git State of the Union

One of my favorite websites is ohshitgit.com (hat tip to Katie Sylor-Miller, Frontend Architect at Etsy for this) - which despite being a developer for years, I visit regularly, because, well…git commands are just hard and unintuitive. We can see this through many git-related resources and ecosystem manifestations.

unix-ninja

@unix_ninja

Git is hard. Screwing up is easy. Documentation is a mess.

Introducing: Oh Shit, Git!?!
😁 ohshitgit.com

13:53 PM - 08 Jun 2021

Whether it's the fact that the Linux Foundation recently announced official Git Certification (which in itself points to a problem…when you need to get certified that implies complexity), or other examples. Such as the multitude of books and cheat sheets written about git, the fact that 5 out of the Top 10 ranked questions of all time on Stack Overflow are about git, and that every company has their own git master that everyone goes to for really serious git debacles.

But it really doesn’t have to be that way––git, or rather source control––is just a means to an end, that is delivering great software. It simply shouldn’t come with so much overhead.

Exhibit 1:

Mark Russinovich

@markrussinovich

Git is the bane of my development process. So easy to get into a state where you have to speak a magic incantation known only to the Git wizards who share their spells on stackoverflow to get things fixed without losing changes.

22:25 PM - 19 May 2021

Exhibit 2:

Hadi Hariri

@hhariri

Git is not a success story. Git is a failure as a system with a crap user experience that forces you to learn more about the tool you're using that about getting your work done.

12:20 PM - 08 Oct 2020

With a bonus XKCD

This overhead comes at a time when developers are already overloaded with tasks and tools that have never really been their responsibility. There’s no doubt that it was much easier to be a programmer 20 years ago––all you really needed to know was…how to code. With all of the shift left movements coming from every single direction––developers are now expected to own basically every product-related discipline: from the engineering, to the security, operations, support, testing, quality and more.

All of these come with their own set of tools and frameworks from a diversity of clouds, containers, scanners and linters, config management and infrastructure as code, load testing and QA tools and much more. Some of these even come with their own languages and syntax, where developers are expected to learn these very well - from the programming languages to the config languages, ops & scripting tools, module repos - from NPM throughPyPI, Terraform and other IaC… and the list goes on.

This is the expectation of devs today, and all this while their primary source control system - git - takes up a significant share of their mental capacity to get right.

So it’s no surprise that developers move more slowly to avoid making mistakes (and the embarrassment that comes along with them), and are slowed down when mistakes happen and they need to fix them, sometimes because of something as basic as the wrong git command.

But How Do Git Mistakes Still Happen?

This begs the question - how is this even possible with all of the existing resources and information available that these types of mistakes still happen with git?

Because RTFM(ing) just doesn’t work anymore in a world of too much documentation, tooling and frameworks. There just isn’t enough time to master each and every tool and read its documentation thoroughly with everything a developer is juggling on a daily basis.

What ends up happening is developers resort to searching for answers. (Remember our stack overflow questions…?) And this can have disastrous outcomes sometimes.

A junior developer at a company I worked at once searched for a git command, and decided to git push –force which impacted all of the developers on the repo. You can imagine how the developer felt, but to be honest this should not have happened in the first place.

Ultimately, your SCM should be a tool that serves to help you, and provide you with the feeling of security that your work is always safe, and not be a constant source of headache and anxiety that you are one push away from disaster.

This is still the case because git remains complicated - there’s too much to learn, and new engineers don’t become experts in git for a while; which also makes it hard to adopt new tooling when you’re still learning git for endless periods of time.

The Source of Git’s Complexity

There are a few elements to the git architecture from where its complexity is derived. Let’s start with decentralization.

If we were to compare git to other existing SCMs at the time––SVN or CVS––git was built to break apart these tool’s centralization, because a centralized repository and server required self-management and maintenance, and was slow. To be able to create and switch branches, and perform complicated merges, you needed blazing fast connectivity and servers, and this just wasn’t available in 2005.

Connections and servers were slow, and branch and other operations would take unreasonable amounts of time. This resulted in workflows without branching, which impacted developer velocity significantly. So in order to improve this bottleneck in engineering, the best solution was to enable all developers to work locally (and cache their changes locally), and push their code to a central repository once the work was completed.

This decentralization and local work though, is also the source of much of the heartache and frustration associated with git––creating many conflicts in versions & branches that can be quite difficult to resolve (particularly with major code changes).

For example, in a centralized SCM there’s only one copy of each branch. Either a commit exists on a branch, or it doesn’t. In Git however, you have local and remote branches. Local branches can track remote branches with different names. You can have different (divergent) histories on the local and remote copies of your branch. This results in the need to work carefully when applying certain operations to a local copy of a branch, which is then pushed to the shared repository (e.g. rebasing), because of the way it might affect others’ work. Simple right? Or not…It’s all rather confusing.

Another source of confusion is the Index, also called the Staging Area. It’s a snapshot of your files, which exists in-between your worktree and the committed version. Why is it needed? Some argue that it helps you split your work into separate commits. Maybe, but it’s definitely not required - for example, Mercurial (very similar to git in most aspects) doesn’t have it, and you can still commit parts of your changes. What it certainly results in is another layer of complexity. Now when comparing changes or resolving conflicts, you need to worry about the staging area AND your worktree. This results in plethora of git command switches, that nobody can memorize - e.g. git reset --soft/hard/mixed/merge 🤦‍♂️, and complicated logic that is sometimes hard to predict.

Yet more confusion stems simply from what seems to be lack of proper UX planning. Git’s CLI is notoriously confusing. There are operations that can be achieved in multiple ways (git branch, git checkout -b), commands that do different things depending on the context (see git checkout), and command switches with completely unintuitive names (git diff --cached? git checkout --guess??). Things would have been simpler if Git’s developers would have given the interface more thought at the beginning. But, it seems that developer experience was not a priority in 2005.

GUI clients and IDE plugins have tried to bridge the DevEx gap, by making Git easier to use through their tools and platforms, but it can’t solve all issues. Eventually, you will inevitably need to use the command line to solve some kind of arcane problem or edge case.

At which point, when this occurs, many just bite the bullet and ask their git guru how to fix the problem. The other option is to avoid the shame of being revealed as a novice (imposter syndrome anyone…?), and to delete the repository (yes, yes including copying all of the local changes aside…), cloning the repo again, and trying to resume work from the previous failure point (without triggering the same conflicts).

The Future of Source Control

The next generation of version control tools should be designed with developer experience in mind. It should be easy to use (easy != not powerful), with intuitive commands (when you need to use CLI), with less pitfalls - so that it’s hard to make embarrassing or costly mistakes or meddle with others’ work.

It should give the developers exactly what they need to manage their code, not more and not less. It should not require you to read a book and understand its underlying data model prior to using it. It should also be usable by non-developers (most software projects today also include non-developers… But that’s a topic for another blog post).

Together with the expectation of better UX, one of the biggest changes that has happened since 2005 is the cloud. Having a centralized repository doesn’t mean managing your own servers anymore. Cloud-based services are scalable, fast, and (for the most part) easy to use. Think Dropbox, Google Docs, Asana, etc.

A new SCM could also take into account the modern DevOps needs, and have powerful API capabilities, deep and even native integrations with existing stacks, and be easily extensible, deriving the inherent benefits available in the cloud of customizability and flexibility. You could define your very own custom processes for pull request approval, CI processes pass/fail, pre-deployment checks and much more. No two teams and companies are the same, as we know, not all PRs were created equal, so how could there be a one-size fits all approach to PR management?

These are the reasons we at Diversion think that it’s time to rethink code management, and rebuild it from the ground up as a cloud-based, modern, scalable and powerful tool with delightful developer experience. Our code management tools should help us save time, collaborate, and give that warm and pleasant feeling that our work is always safe - and not the opposite.