Version Control:

Version control is a class of systems responsible for managing changes to computer programs,
documents, large web sites, or other collections of information.

Version control is a component of software configuration management

History:

IBM's OS/360 IEBUPDTE software update tool dates back to 1962, arguably a precursor to version
control system tools.

Description:

support programs included in or available for OS/360 and successors. IBM categorizes some of these
programs as utilities. IEBUPDTE Used to add, update or delete a member of a PDS (partition Data
set)

---------------------------------------------------------------------------------------------------------------------------

A full system designed for source code control was started in 1972, Source Code Control System for
the same system (OS/360). Source Code Control System's introduction, having been published on
December 4, 1975, historically implied it was the first deliberate revision control system.

Description:

Source Code Control System (SCCS) is a version control system designed to track changes in source
code and other text files during the development of a piece of software. This allows the user to
retrieve any of the previous versions of the original source code and the changes which are stored. It
was originally developed at Bell Labs beginning in late 1972 by Marc Rochkind for an IBM
System/370 computer running OS/360.

A characteristic feature of SCCS is the sccsid string that is embedded into source code, and
automatically updated by SCCS for each revision.[2] This example illustrates its use in the C
programming language:

static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/11/93";

This string contains the file name, date, and can also contain a comment. After compilation, the
string can be found in binary and object files by looking for the pattern "@(#)" and can be used to
determine which source code files were used during compilation. The "what" command [1] is
available to automate this search for version strings.
RCS followed just after, with its networked version Concurrent Versions System.

Description:

Revision Control System (RCS) is an early implementation of a version control system (VCS). It is a set
of UNIX commands that allow multiple users to develop and maintain program code or
documents. With RCS, users can make their own revisions of a document, commit changes, and
merge them. RCS was originally developed for programs but is also useful for text documents or
configuration files that are frequently revised

RCS was first released in 1982 by Walter F. Tichy at Purdue University. It was an alternative tool to
the then-popular Source Code Control System (SCCS) which was nearly the first version control
software tool (developed in 1972 by early Unix developers). RCS is currently maintained by the GNU
Project.

RCS operates only on single files. It has no way of working with an entire project, so it does not
support atomic commits affecting multiple files. Although it provides branching for individual files,
the version syntax is cumbersome. Instead of using branches, many teams just use the built-in
locking mechanism and work on a single head branch.

an atomic commit is an operation that applies a set of distinct changes as a single operation

CVS

Concurrent Versions System (CVS, also known as the Concurrent Versioning System) is a revision
control system originally developed by Dick Grune in July 1986.

CVS operates as a front end to RCS, an earlier system which operates on single files. It expands upon
RCS by adding support for repository-level change tracking, and a client-server model.

------------------------------------------------------------------------------------------------------------------------------------

Subversion

Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning
and revision control system distributed as open source under the Apache License. Software
developers use Subversion to maintain current and historical versions of files such as source code,
web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used
Concurrent Versions System (CVS).

The open source community has used Subversion widely: for example, in projects such as Apache
Software Foundation, Free Pascal, FreeBSD, SourceForge, and from 2006 to 2019, GCC. CodePlex
was previously a common host for Subversion repositories.

Subversion was created by CollabNet Inc. in 2000, and is now a top-level Apache project being built
and used by a global community of contributors
DVC

distributed version control (also known as distributed revision control) is a form of version control in
which the complete codebase, including its full history, is mirrored on every developer's
[Link] to centralized version control, this enables automatic management branching
and merging, speeds up most operations (except pushing and pulling), improves the ability to work
offline, and does not rely on a single location for [Link], the world's most popular version
control system, is a distributed version control system.

Distributed version control systems (DVCS) use a peer-to-peer approach to version control, as
opposed to the client–server approach of centralized systems. Distributed revision control
synchronizes repositories by transferring patches from peer to peer. There is no single central
version of the codebase; instead, each user has a working copy and the full change history.

GIT

Git development began in April 2005, after many developers of the Linux kernel gave up access to
BitKeeper, a proprietary source-control management (SCM) system that they had been using to
maintain the project since 2002The copyright holder of BitKeeper, Larry McVoy, had withdrawn free
use of the product after claiming that Andrew Tridgell had created SourcePuller by reverse
engineering the BitKeeper [Link] same incident also spurred the creation of another version-
control system, Mercurial.

Linus Torvalds wanted a distributed system that he could use like BitKeeper, but none of the
available free systems met his needs. Torvalds cited an example of a source-control management
system needing 30 seconds to apply a patch and update all associated metadata, and noted that this
would not scale to the needs of Linux kernel development, where synchronizing with fellow
maintainers could require 250 such actions at once. For his design criterion, he specified that
patching should take no more than three seconds, and added three more goals:

Take Concurrent Versions System (CVS) as an example of what not to do; if in doubt, make the exact
opposite decision.

Support a distributed, BitKeeper-like workflow.

Include very strong safeguards against corruption, either accidental or malicious.

These criteria eliminated every version-control system in use at the time, so immediately after the
2.6.12-rc2 Linux kernel development release, Torvalds set out to write his own.

The development of Git began on 3 April [Link] announced the project on 6 April and became
self-hosting the next [Link] first merge of multiple branches took place on 18 April.[18] Torvalds
achieved his performance goals; on 29 April, the nascent Git was benchmarked recording patches to
the Linux kernel tree at the rate of 6.7 patches per [Link] 16 June, Git managed the kernel
2.6.12 release.
Torvalds turned over maintenance on 26 July 2005 to Junio Hamano, a major contributor to the
[Link] was responsible for the 1.0 release on 21 December 2005 and remains the project's
core maintainer.

Git Hub:

GitHub, Inc. is a provider of Internet hosting for software development and version control using Git.
It offers the distributed version control and source code management (SCM) functionality of Git, plus
its own features. It provides access control and several collaboration features such as bug tracking,
feature requests, task management, continuous integration and wikis for every project.
Headquartered in California, it has been a subsidiary of Microsoft since 2018.
Development of the [Link] platform began on October 19, 2007. The site was launched in
April 2008 by Tom Preston-Werner, Chris Wanstrath, P. J. Hyett and Scott Chacon after it had
been made available for a few months prior as a beta release. GitHub has an
annual keynote called GitHub Universe.[

------------------------------------------------------------------------------------------------------------------------------------

Gitlab:

A brief history of GitLab

2021: 10 Years of GitLab

This year we celebrated 10 years of GitLab, marking a decade since the first commit was made! Our
focus on community contributions remained strong, averaging more than 650 code contributions a
month from over 2500 wider community contributors. Thanks to our DevOps Platform, we grew to
more than 1 million active license users and 30+ million estimated registered users as of August
2021. GitLab, the company, grew to over 1400 team members in 65 countries and regions around
the world. We continued to support and educate businesses about the benefits of remote work by
leading more than 60 collaborative remote work discussions with companies, VCs and universities
since the beginning of the pandemic.

On October 14, 2021, GitLab Inc. became a publicly traded company on the Nasdaq Global Market
(NASDAQ: GTLB).

Watch the video of GitLab's Listing Day

2020: The world's largest all-remote company

With over 1,200 team members in more than 65 countries, we believe we were the world's largest
all-remote company prior to the COVID-19 pandemic. Every single team member is remote, with no
central headquarters and no company-owned offices anywhere in the world. GitLab has raised
$426M to date.
2019: Contribute

Haydn Mackay delivered a wonderful keynote at GitLab Contribute in New Orleans detailing GitLab's
history. As one of GitLab's earliest employees and an inspiration for GitLab's all-remote culture,
Haydn provided a uniquely comprehensive view of GitLab's evolution.

2017: GitLab Storytime

A team member at GitLab interviewed the first five team members from GitLab to hear stories from
the first years. In Storytime Part 1 the team talks about hiring its first team member, learning to
iterate, thoughts of shutting down, Y Combinator, and how the values were created. In Storytime
Part 2, we hear some hilarious stories of a surprise bachelor party, a competitor’s offer to talk, a
presentation that involved a lab coat and safety goggles, the first GitLab summit, and experiences at
the Mountain View House.

2016: Growth

In 2016 the number of people that contributed to GitLab grew to more than 1000. More than
100,000 organizations and millions of users are using GitLab. Our team grew with 100 people to
more than 140. In September we announce our master plan and raising $20m in our B round of
financing.

2015: Y Combinator

In the very start of 2015, almost the entire GitLab team flew over to Silicon Valley to participate in Y
Combinator.

We became much more comfortable with a much faster pace, and it changed the way we thought
about what we could achieve in a short timeframe. If we think something takes too long, we need to
change our idea of what we can accomplish. There is always an opportunity to do something smaller
and imperfect but that still makes a difference.

It was essential to the trajectory we've set. We never thought we could beat our competitors, but
we had big ambitions and knew we had a great product and would continue to iterate and improve
on that product, which we still do today.

We graduated in March of 2015 and had 9 people on our team. The GitLab Handbook was added to
the website repository.

2014: GitLab was incorporated

2013: "I want to work on GitLab full time"

Large organizations running GitLab asked Sid to add features that they needed. At the same time
Dmitriy tweeted out to the world that he wanted to work on GitLab full time. Sid and Dmitriy
teamed up and introduced GitLab Enterprise Edition with the features asked for by larger
organizations. Sid authored the initial commit on GitLab's website repository.

2012: [Link]

Sid saw GitLab for the first time and thought it was natural that a collaboration tool for programmers
was an open source so you could contribute to it. Being a Ruby programmer he checked out the
source code and was impressed with the code quality of GitLab after more than 300 contributions in
the first year. He asked Hacker News if they were interested in using [Link] and hundreds of
people signed up for the beta. In November 2012, Dmitriy made the first version of GitLab CI.

2011: Start of GitLab

GitLab's co-founder Dmitriy Zaporozhets needed a great tool to collaborate with his team. He
wanted something efficient and enjoyable so he could focus on his work, not the tools. He created
GitLab from his house in Ukraine. It was a house without running water but Dmitriy perceived not
having a great collaboration tool as a bigger problem than his daily trip to the communal well.

So together with Valeriy Sizov, he started to build GitLab as a solution for this. This commit was the
very start of GitLab on October 8, 2011.

The GitLab name was inspired by GitWeb and other git products.
DVCS
Repository: