What non-tech founders should know about version control

A lot of startups today are founded by non-tech founders more proficient in business development and team management than actual production process. Often these people have trouble understanding version control and yet the right choice can speed up development and improve code quality.

Without an experienced tech co-founder the non-tech business owner is left with two choices: either trust the dev team entirely and leave all development decisions to them or educate themselves about the basics of product development and make informed choices throughout the project.

One of the important tools of product development is a version control system. The choice of a version control system is among the first that you will need to make to start development. It affects both the speed of production (time is money!) and code quality. So it’s not something to take lightly.

Bearing all that in mind let’s take a look at what version control systems dominate the market and which one suits your project best.

Centralized version control systems

Centralized version control

Subversion or SVN is the most popular centralized version control tool on the market. Along with CVS it used to dominate the version control scene for more than a decade. SVN can also be a great solution for managing non-development content in a project -- such as graphics or text assets.

Centralized version control is based on a client-server architecture. The server works as a single access point which brings both advantages and disadvantages to this solution. Let’s talk about the good parts of SVN first.

Advantages:

  • strict control over source code;
  • better handling of binary files;
  • simpler workflows;
  • improved file change tracking compared to git;
  • confidentiality for closed source projects.

When experts talk about the weak spots of centralized version control, they usually point out the issues of harder code merging and a crucial dependency of the whole team on a single server. If the server is unavailable the whole work process is slowed down to a halt.

Main disadvantages:

  • worse performance compared to Git;
  • most SVN functions require you to be online;
  • code merges are hard to implement and require more time.

SVN lost the popularity contest since approximately 2011 because of the rise of new shiny distributed version control systems such as Git and Mercurial – and later a surge of “social coding” hype based on GitHub and GitLab platforms.

 

Distributed version control systems

Instead of using a single server to commit changes a distributed version control system creates an environment where all copies of the repository circulate in a peer-to-peer network with dozens of local branches that exist only on the hard drives of individual developers and nowhere else.

A distributed version control model was initially designed to provide better flexibility and convenience for open source development. And such solutions as Git and Mercurial work really well for loose teams of contributors that develop in an open source environment.

Distributed version control creates both new possibilities and challenges for the development team. Let’s talk about the pros first.

Advantages of using a DVCS:

  • better overall performance;
  • no dependency on the central server, most work is offline;
  • access to all files, no need to request read/write privileges;
  • easier code merging and conflict resolution.

But does the busywork with distributed version control systems pay off? There are a lot of drawbacks to using them in the project.

Main disadvantages include:

  • no access control (which can create security concerns);
  • full copy of repository on every computer;
  • harder to scale for larger projects;
  • increased workflow complexity;
  • no file protection (data integrity concerns).

Since DVCS are less suited for larger projects where repositories can reach many gigabytes of data, the common practice is to fragment a big project into smaller repositories. While this tactics allows developers to limit the scalability challenge, it complicates maintenance, adding more work to the DevOps team that now has to monitor inconsistent project branches and manage repositories for release and testing purposes.

Differences between centralized and distributed version control

Distributed version control allows developers to commit more often adding less code each time. This speeds up the development process as new code is reviewed faster and new functionality is tested in smaller chunks alleviating the pressure from the testing team.

One line changes are treated the same as adding whole blocks of new code. They are tested and merged with the same approach to stability and code cleanliness as any other code commits.

In a centralized environment branches are global. This means that centralized version control systems such as SVN are cumbersome to use. Newly created branches inconvenience everyone on the project. They need to mirror new branches through the central server to be up-to-date with overall development.

Uncontrollable growth of new branches makes everybody's repositories bigger and bulkier – eventually harder to maintain.

How Git conquered our hearts

If you ask a typical non-tech founder what version control system their team uses they wouldn’t know. But there’s another problem that lies here. When you ask a tech founder the same question they will most likely say they decided to go with Git or Mercurial, the two most common version control tools on the market.

Why is that?

Why seemingly everyone has switched to DVSC around 2011? First let’s look at the facts.

According to RhodeCode team who in 2016 decided to find out the relative popularity of version control systems, developer opinion was more or less uniform. Of 881 voters on Twitter 87% used Git, 6% used SVN, 5% used Mercurial, and 2% used Perforce (another centralized version control tool popular within the gamedev community).

Throughout the years version control preferences have shifted from centralized to distributed-based models. The main reason of DVCS popularity lies in GitHub, a social coding platform that gained enormous popularity within the developer community. GitHub serves as the main source hosting portal for individual development projects, developer portfolios, and open source projects.

And since GitHub uses Git as the underlying tech tool, developers grew to love it as well.

What version control system is right for your project

2014 was the year when Git and in particular GitHub completely conquered the hearts of developers and SVN lost ground. GitHub contributed a lot to this victory since it offered free project hosting for open source development teams.

While Git and SVN may have been competing with each other for more than 10 years now, the battle between centralized and distributed version control solutions is not over yet.

The statistics we see on the Internet does not take into account numerous closed source projects and commercial project development hosted in private environments.

So study your real development challenges and choose according to your real needs, not the hype in the development community.

Choose Git if:

  • your team is working on an open source project or you don’t mind that every developer can see all the source code of the project;
  • your team might have issues in accessing the centralized server (e.g. some developers have poor Internet connection or server health is challenged);
  • you have an experienced team that knows Git really well (this will eliminate security and access issues, as well as eliminate some of the Git’s quirkiness);
  • you have a strong DevOps team that will help you maintain a large project spanning multiple repositories with dozens of developers working on things simultaneously.


Choose SVN if:

  • you manage your team and the development process in a centralized way;
  • you need a single repository for your project;
  • you want a simpler workflow or don’t have the capacity to maintain complexity;
  • your binary assets management is a concern;
  • your project is large with sizes reaching 1+ Gb or more;
  • your team has a steady Internet access at all times.
TAGS

Comments (0)

Name

Field is required

Email

Enter valid email

Message

Field is required
Thanks for your response! Your comment is pending administrator's approval.