Distributed version control: Difference between revisions

Revision as of 12:24, 19 March 2024

Revision as of 12:31, 19 March 2024

Line 36:

Some originally centralized systems now offer some distributed features. [[Team Foundation Server]] and Visual Studio Team Services now host centralized and distributed version control repositories via hosting Git.

Similarly, some distributed systems now offer features that mitigate the issues of checkout times and storage costs, such as the [[Virtual File System for Git]] developed by Microsoft to work with very large code basescodebases,<ref>{{cite web|author=Jonathan Allen|url=https://www.infoq.com/news/2017/02/GVFS/|title=How Microsoft Solved Git's Problem with Large Repositories|date=2017-02-08|access-date=2019-08-06}}</ref> which exposes a virtual file system that downloads files to local storage only as they are needed.

==Work model==

{{Expand section|date=June 2008}}

Distributed model also known as distributed version control system is basically for managing and merging code. It has multiple repositories that can work on multiple ends. So, Each user has his own repository and working copy and all the changes will reflect on local repositories and we need to push them to make changes permanently. The distributed model is generally better suited for large projects with partly independent developers, such as the Linux kernel project, because developers can work independently and submit their changes for merge (or rejection). The distributed model flexibly allows adopting custom source code contribution workflows. The [[integrator workflow]] is the most widely used. In the centralized model, developers must serialize their work, to avoid problems with different versions.

== =Central and branch repositories ===

== Distributed version control System Architecture ==

In a truly distributed project, such as [[Linux]], every contributor maintains their own version of the project, with different contributors hosting their own respective versions and pulling in changes from other users as needed, resulting in a general consensus emerging from multiple different nodes. This also makes the process of "forking" easy, as all that is required is one contributor stop accepting pull requests from other contributors and letting the code basescodebases gradually grow apart.

This architecture employs a peer-to-peer approach, where each peer possesses a local repository akin to the original source repository. What sets it apart is that every clone constitutes a fully functional repository that operates independently of network access or a central server. Synchronization occurs through the exchange of patches (change sets) via peer-to-peer communication, enabling autonomous developers to work asynchronously.

This arrangement, however, can be difficult to maintain, resulting in many projects choosing to shift to a paradigm in which one contributor is the universal "upstream", a repository from whom changes are almost always pulled. Under this paradigm, development is somewhat re-centralizedrecentralized, as every project now has a central repository that is informally considered as the official repository, managed by the project maintainers collectively. While distributed version control systems make it easy for new developers to "clone" a copy of any other contributor's repository, in a central model, new developers always clone the central repository to create identical local copies of the code base. Under this system, code changes in the central repository are periodically synchronized with the local repository, and once the development is done, the change should be integrated into the central repository as soon as possible.

Since Linus Torvalds delivered a presentation at Google on a distributed version control system named GIT in May 2007, the adoption and interest in Distributed Version Control Systems have steadily increased.

In contrast to centralized VCS, where most operations are performed on the server side, acting as a single point for all actions while clients hold only a working copy of the codebase, distributed VCS grants each client, referred to as a collaborator, its own local repository. Here, branches, tags, and commit information reside on the local machine. While there is no central server per se, any repository can be configured as a central repository to serve as a source of truth and integrate with build and deployment tools such as Jenkins and Chef

== Central and branch repositories ==

In a truly distributed project, such as [[Linux]], every contributor maintains their own version of the project, with different contributors hosting their own respective versions and pulling in changes from other users as needed, resulting in a general consensus emerging from multiple different nodes. This also makes the process of "forking" easy, as all that is required is one contributor stop accepting pull requests from other contributors and letting the code bases gradually grow apart.

This arrangement, however, can be difficult to maintain, resulting in many projects choosing to shift to a paradigm in which one contributor is the universal "upstream", a repository from whom changes are almost always pulled. Under this paradigm, development is somewhat re-centralized, as every project now has a central repository that is informally considered as the official repository, managed by the project maintainers collectively. While distributed version control systems make it easy for new developers to "clone" a copy of any other contributor's repository, in a central model, new developers always clone the central repository to create identical local copies of the code base. Under this system, code changes in the central repository are periodically synchronized with the local repository, and once the development is done, the change should be integrated into the central repository as soon as possible.

Organizations utilizing this centralize pattern often choose to host the central repository on a third party service like [[GitHub]], which offers not only more reliable [[uptime]] than self-hosted repositories, but can also add centralized features like [[issue trackers]] and [[continuous integration]].

== =Pull requests ===

Contributions to a source code repository that uses a distributed version control system are commonly made by means of a '''pull request''', also known as a '''merge request'''.<ref name="gitlab-merge-req">{{cite web|last=Sijbrandij|first=Sytse|title=GitLab Flow|date=29 September 2014|access-date=4 August 2018|website=GitLab|url=https://about.gitlab.com/2014/09/29/gitlab-flow/}}</ref> The contributor requests that the project maintainer ''pull'' the source code change, hence the name "pull request". The maintainer has to ''merge'' the pull request if the contribution should become part of the source base.<ref name="ossw">{{cite web|last1=Johnson|first1=Mark|title=What is a pull request?|url=http://oss-watch.ac.uk/resources/pullrequest|website=Oaawatch|access-date=27 March 2016|date=8 November 2013}}</ref>

Line 86 ⟶ 80:

==References==

<ref>[https://www.geeksforgeeks.org/version-control-systems/ version control systems] Especially section "types of version control system"</ref>

<ref>[https://www.irejournals.com/formatedpaper/1701230.pdf Research Paper on Distributed Version Control systems] IRE Journals</ref>

{{reflist}}

Line 96 ⟶ 88:

{{Version control software}}

{{DEFAULTSORT: Distributed Revision Control}}

[[Category:Version control]]

[[Category:Free software projects]]