Version control and Git

Sat, 07 May 2022 18:30:00 +0000

Modification Control Systems (VCS) allow you to track changes in your code, look through history to look for specific changes, and coordinate work on the same code base between multiple developers. Today we will look at how one of the most popular VCS, Git, works.

Story

Git was developed in 2005 by Linus Torvalds to help develop the Linux kernel. Shortly before this, there was a scandal with Bitkeeper, a proprietary version control system that was used by many developers, but was no longer available for free after the copyright holder found out that it was reverse-engineered to create SourcePuller.

The goals of the project were: to make a distributed VCS that could support a procedure similar to Bitkeeper, but was also fast (no more than three seconds to apply a patch) and had strong protection against errors and unintentional modifications.

Principles

Git’s primitive data structures do not necessarily implement VCS. There are two places where information is stored – a dynamic index that describes the state of the working tree, and an immutable object database. The latter stores the following five types of objects:

BLOB – the content of the file, denoted by its hash. Each BLOB is a separate version of a file.
a tree is analogous to a directory, which has links to sub-trees and BLOBs to represent one version of the working tree.
A commit is a history element pointing to the tree it describes and one or more previous commits.
tag - an object that has a link to some other object and some additional information about this object. Most commonly used to add digital signatures to commits.
packfile – a file containing several other objects in a compressed format for compactness.

Because of this design, each repository contains the entire history and can be viewed locally. This is what makes Git distributed VCS.

The commit history is structured as a singly-linked tree, and because the identifiers are based on a cryptographic hash of the content, this can also be thought of as a blockchain instance. Each commit can have a parent, the commit that the changes are based on. With the help of them you can go back to the history of changes. Since each commit is identified by its hash, any change in history requires the hash of each object to be recalculated further, which provides cryptographic protection against changes.

In addition to this, Git maintains a linkbase. Head objects point to the latest commit on a branch, they call the branch, and are in fact branches. One special head, called HEAD, points to the current branch from which the comparison to the working tree is being made. There are also tags, which, like head, indicate commits, but unlike them do not move, and can instead be used to mark important points in the project’s history.

History keeping process

Git does not dictate how a project’s history should be maintained. One option that is supposed to be used in the OS course involves short-lived branches within which work is done to implement a new feature, and then this branch is merged into the main tree when the feature is completed. Other options include long-lived branches ranked by code stability, or branches assigned to specific team members.

Different methods have their pros and cons, which are more or less obvious depending on the type of project and the development methodology that the team uses.

Conclusions

Git is one of the most popular VCS, and for good reason. It was written to solve problems with existing SLEs, and it was able to solve them much more effectively than any other solution at the time.

One of the factors behind its popularity has been the rise of Git hosting services such as GitHub, GitLab, and BitBucket. These services allow you to publish a Git repository and make it available from the web, and their convenience has led many users to now associate Git with GitHub.

With such popularity, ease of casual use, and yet depth of functionality for advanced use, Git is now a must for any kind of code development. That is why in the OS course we learn the basics of using Git.

Weekly post 18

Sat, 07 May 2022 18:30:00 +0000

This is a weekly post that is required by the rules for maintaining a personal project. This post was written on May 7, 2022, and covers week 18, 2022.

How was the week

Overall, week 18 was similar to week 17, and both were more productive than week 16. This is because the format of this course is still unfamiliar and goes against my previous experience. Therefore, according to the sensations, it turned out only to do the work at the rate of the OS and nothing more useful.

Key insights

The AVR architecture has three system timers. The first one is usually used for real time tracking, the second one for precise PWM signals, and the third one for approximate PWM signals.
As before, the model of reality based on the theory of complete determinism with the addition of randomness through quantum mechanics seems to be the most accurate description of reality.
The video game The Stanley Parable: Ultra Deluxe (2022) puts forward a model of reality based on the central thesis that everything (with the possible exception of the narrator and the player character) is a bucket, and therefore any attempt to limit the number of buckets in the world inevitably leads to the destruction of the world in the current understanding. This model must be carefully considered by the engineers of metaphysics to determine its scope.

Main insight

With the understanding that all timing in the AVR is done with three timers, it is now possible to write code that connects one of the timers to the pins on the chip, allowing you to implement PWM signals from scratch as part of the Rust Arduino environment project.

What failed to do

As in weeks 16 and 17, there is a feeling that almost nothing can be done from the plans. This feeling is based on the fact that the work on the OS course takes a very long time and requires full concentration (due to the fact that the video is being recorded), and after completing one stage, it is difficult to convince yourself to do the next. It basically boils down to the fact that I have not yet developed a stable strategy for allocating work and rest time, which, combined with the drastic change in the load profile, leads to this feeling of lack of progress.

Work on mistakes

In order to solve the above problems, the most promising solution is to develop task allocation schemes that are comfortable enough for everyday use and that allow active tasks to be solved more efficiently.

Week 18 | Project site in English