UNIT 3

Source Code Management

1960s
The predecessor of modern version control tools was IEBUPDTE, which was used with IBM's OS/360. It was developed in
the early 1960s and primarily used punched cards to store data. While there is some debate over whether IEBUPDTE
constitutes ‘true’ version control, it did provide the ability to create and update libraries of code in a way that’s similar to
today’s patching systems.

1970s
In 1972, Bell Labs made a breakthrough in the field of version control. They created SCCS (Source Code Control System),
which was written in C and developed by Marc Rochkind. This system shared many characteristics with modern version
control systems such as the ability to create, edit, and track changes to files. However, it lacked the ability for more than
one user to check out and work on a file at the same time. SCCS was made available to the public in 1977 and was the
primary version control system into the early 1980s.
1980s
In 1982, Walter Tichy developed a new system called RCS, or Revision Control System. RCS still only allowed one user at a
time to make edits and only supported the ability to work on single files, rather than a whole project. However, it did
pioneer a new way of tracking changes called reverse deltas. Rather than store all of the versions of a file, RCS used a single
recent version as its baseline from which all other versions were created. For the time, this was a faster and more efficient
way of tracking changes.

A few years later in 1986, Dick Grune developed CVS (Concurrent Versions Systems), which was also written in C. CVS finally
allowed more than one developer to work on a file at the same time. Users would deploy the UpdateVersion command to
update a file to the latest version of that file on the server. CVS used delta encoding or compression, which tracks
differences but not entire versions of files. With its use of a client-server model and branches, CVS is a much more modern
example of version control.
1990s to present

The next major version control system was Subversion (SVN), which was created in 2000 by CollabNet. SVN preserved
many of the features included in CVS so that users could easily transition between the two. By 2010, SVN was renamed
Apache Subversion after it became part of the Apache Software Foundation.

SVN is an example of a centralized version control system (CVCS). Changes are made to a single copy of the project on a
server and other users can pull down the latest version of the project to make their edits. There are many Subversion
clients still in use today, such as Tortoise SVN and SmartSVN. However, CVCS has been eclipsed in recent years by a more
modern form of version control: the distributed version control system (DVCS).

Currently, the most well-known DVCS is Git, which was created in 2005 by Linus Torvalds. The basic logic behind a DVCS is
that a copy of the repository and its history is downloaded by every user. Systems like Git are known for being fast and
reliable, with good branching capabilities. For now, it seems that DVCS is the future of version control, but as repositories
continue to grow in size, it may be necessary to innovate even further.
History - Linux and Git by Linus Torvalds

It all started with Linus Torvalds, the creator of Linux. In 2005, he was frustrated by losing a free license for BitKeeper, the
version control system that the Linux kernel community had been using. This license dispute left the community in need of
a free, open-source alternative. Linus decided to create his version control system. Linus chose to call it Git, which is British
slang for “unpleasant person,” because “I’m an egotistical bastard, and I name all my projects after myself. First Linux, now
Git.”

Creating Git wasn’t an easy process. It took Linus Torvalds two weeks to write the initial version of Git, and the first commit
was made in April 2005. Later that year, in December, the first official version of Git was released. Adoption came quickly;
the Linux kernel community began using Git as their version control system shortly after its creation, and other open-
source projects soon followed.

However, it wasn’t until 2008, when GitHub was launched, that Git took off. GitHub made it incredibly easy to host Git
repositories and collaborate with other developers, and soon Git became the go-to version control system for open-source
projects.
PARALLEL DEVELOPMENT
GIT COMMON COMMANDS
WORKING WITH REMOTE
REPOSITORIES
Action Items
• Create a local git repository and move the entire code base to it
• Create a new branch for a new feature you want to add to the application
• Merge back the created branch with the master branch
• Create a remote repository
• Push the local repository to the company’s remote repository
Private Workspace
• The repository is essentially the .git hidden
folder inside the working directory (workspace).

• The working directory (workspace) is

essentially our project folder.

• Synonyms: workspace = working directory

= project folder
Step 1: Creating a working directory/workspace

Step 2: Creating a repository –

git init
Step 3: The working directory and repository
in-depth

The amazing-project folder represents our working directory:

And the .git folder represents our repository:
Step 4: Adding a file
Step 5: Adding the file to our repository

The 'git add' command copies the file from the working directory to
the staging area.
Example Workflow Using Private Workspaces

[Link] Repository:

git clone <repository-url>

[Link] a Feature Branch:

git checkout -b feature/my-feature

[Link] Changes Locally: Edit files, run tests, and commit privately.

[Link] Changes:

git commit -m "Add new feature"

[Link] When Ready: Share changes with the team by pushing to a remote branch:

git push origin feature/my-feature.