How Version Control Tools Evolved

N.B : Writing about things helps me understand how things work end to end because it forces you to fill the gaps you have in your mind when you only think about things – I wrote about this here

There are so many version control tools available, the most popular one I would say is Git among so many others like CVS, Subversion, Mercurial etc.

I will be explaining the difference between the different generation of tools and how they evolved in this article.

GenerationNetworkingOperationsConcurrencyExamples
FirstNoneOne file at a timeLocksRCS, SCSS
SecondCentralizedMulti-fileMerge before commitsCVS, SourceSafe, Subversion, Team Foundation Server
ThirdDecentralizedChangesetsCommit before mergeBazaar, Git, Mercurial

Table showing the history of Version Control Tools
Reference: erikson.com

First Generation Version Control Tools

Networking

No networking was available at this time , users had to login to the system (UNIX at the time) where the project was to work on it.

Concurrency

They implemented concurrent development with locks, meaning only one person could be working on a file at a time.

Operation

They worked only with files, they had no way of tracking changes in an entire project. Although it supported branching but the syntax was cumbersome, many people just used a single development branch with locking mechanism on files.

Second Generation Version Control Tools

Networking

They allowed projects to be hosted on a central server with all the branching happening on the central server usually via a server-client and was impossible to get the repository to your computer.

Concurrency

Working branch had to be updated before commit can be made. If user A and user B were working on the same branch and user A makes some commits and then user B tries to make his/her own commits, he/she gets denied because his/her branch is now out of sync and has to forcefully update and resolve conflicts on his/her branch before the commit can be made.

Operations

Commits were being done on files. It was however also possible to commit multiple files at once. This commit operation sends all the changes from the server-client to the central server.

Third Generation Version Control Tools

Networking

They allowed repositories to be distributed, this meant multiple users can work on the same project repository on their local computers and then can synchronise with another repository of the same project hosted on a server.

Concurrency

Commits could be made without syncing the local branch with the remote repository. This meant that user A and user B working on the same branch could make multiple as they wish on their local repositories and any one of them could resolve conflicts when merging to the remote repository.

Operation

Supported atomic commits affecting multiple files and thus creating a changeset. A changeset is a state of the whole repository.

References & Additional Resources

OPCode Caching – PHP

N.B : Writing about things helps me understand how things work end to end because it forces you to fill the gaps you have in your mind when you only think about thingsI wrote about this here

PHP is an interpreted language, although shares some similarities with other compiled languages like java in how it parses and compiles its source files.

Java for example compiles source code to bytecodes which can be saved as a binary and then executed over and over again on a Virtual machine (JVM).

PHP also compiles its source code to an intermediate language called the OpCodes but unlike compiled languages, a binary file is not generated that can be executed over and over again. Instead, we go through the whole parsing and compilation process each time we execute the script even when there are no changes.

PHPJavaLifeCycle.png

PHP Interpreter vs Java Compiler
Reference: support.cloud.engineyaard

The OpCode Caching was created to prevent parsing and compiling the source code every time the same script was executed. It saves the OpCodes for a script the first time and then uses the OpCodes in the cache for subsequent requests for the same script.

PHPOpCodeLifeCycle.png

Modified PHP execution flow with the OpCode Cache Enabled.
Reference: support.cloud.engineyaard

The Zend OpCache comes bundled with recent PHP versions (5.5+) and to enable it is pretty easy, just set the  opcache.enable=1 in your php.ini file. You can install Zend OpCache for older PHP versions and also check the documentation here: ZendOptimizerPlus.

Enabling the OpCache in the development environment is not advisable because it can cause your changes not to reflect immediately which can be quite annoying. You can follow this article here: laravel-news-php-opcache-docker If you have your application dockerized and want to disable OpCache only in development environment.

Additional Resources: