Content deleted Content added
I expanded the article by adding more detailed subheadings, elaborating on the advantages and contrasts of distributed version control systems (DVCS) compared to centralized systems, and providing more insights into managing distributed projects, integration processes, and collaboration methods. Tags: Reverted references removed Visual edit Newcomer task |
Reverted 1 edit by Brahim.Lamrabet (talk): Spam |
||
Line 1:
{{Short description|Software engineering tool}}
In [[software development]], '''distributed version control''' (also known as '''distributed revision control''')
| url=http://joelonsoftware.com/items/2010/03/17.html
| first=Joel
| last=Spolsky
| title=Distributed Version Control Is Here to Stay, Baby
| work=Joel on Software
| date=17 March 2010
| access-date=4 June 2019}}</ref>
Distributed version control systems (DVCS)
▲Distributed version control systems (DVCS) adopt a peer-to-peer approach to version control, differing from the client-server approach of centralized systems. Synchronization of distributed revision control occurs by transferring patches directly between peers. There is no singular central version of the codebase; instead, each user possesses a working copy alongside the complete change history.
* Allows users to work productively when not connected to a network.
* Common operations (such as commits, viewing history, and reverting changes) are faster for DVCS, because there is no need to communicate with a central server.<ref name='OSullivan'>{{cite web
| last = O'Sullivan
| first = Bryan
| title = Distributed revision control with Mercurial
| url = http://hgbook.red-bean.com/hgbook.html
| access-date = July 13, 2007 }}</ref> With DVCS, communication is necessary only when sharing changes among other peers.
* Allows private work, so users can use their changes even for early drafts they do not want to publish.{{cn|date=August 2019|reason=This isn't unique to dvcs; any source code control system allows 'private work', though on some it requires changing (private) file permissions}}
* Working copies
* Allows various development models to be used, such as using [[Branching (version control)#Development branch|development branches]] or a Commander/Lieutenant model.<ref>{{cite book|first1=Scott|last1=Chacon|first2=Ben|last2=Straub|edition=2nd|date=2014|publisher=Apress|at=Chapter 5.1|chapter=Distributed workflows|chapter-url=https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows|title=Pro Git}}</ref>
* Permits centralized control of the "release version" of the project{{cn|date=August 2019|reason=Not specific to dvcs; centralized systems generally control release version}}
* On [[FOSS]] software projects it is much easier to create a [[Fork (software development)|project fork]] from a project that is stalled because of leadership conflicts or design disagreements.
* Initial checkout of a repository is slower as compared to checkout in a centralized version control system, because all branches and revision history are copied to the local machine by default.
*
* Additional storage required for every user to have a complete copy of the complete codebase history.<ref>{{cite web|title=What is version control: centralized vs. DVCS|url=https://www.atlassian.com/blog/software-teams/version-control-centralized-dvcs|website=www.atlassian.com|date=14 February 2012 |access-date=7 January 2018}}</ref>
*
Some originally centralized systems now
▲* Working copies serve as effective remote backups, mitigating reliance on a single machine as a potential point of failure.
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 codebases,<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.
▲Disadvantages of DVCS (compared to centralized systems) include:
▲* Lack of locking mechanisms crucial for handling non-mergeable binary files like graphics or complex single-file binary/XML packages (e.g., office documents, PowerBI files, SQL Server Data Tools BI packages, etc.).
▲* Higher exposure of the code base, as each participant possesses a locally vulnerable copy.
▲Some originally centralized systems now integrate distributed features. For instance, Team Foundation Server and Visual Studio Team Services host both centralized and distributed version control repositories via Git hosting.
==Work model==
{{Expand section|date=June 2008}}
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). This flexibility allows adopting custom source code contribution workflows, such as the [[integrator workflow]], which is the most widely used. Unlike the centralized model where developers must serialize their work to avoid problems with different versions, in the distributed model, developers can clone the entire history of the code to their local machines. They commit their changes to their local repositories first, creating 'change sets,' before pushing them to the master repository. This approach enables developers to work locally and disconnected, making it more convenient for distributed teams.<ref>{{Cite web |last=Upadhaye |first=Annu |date=22 Feb 2023 |title=Centralized vs Distributed Version Control |url=https://www.geeksforgeeks.org/centralized-vs-distributed-version-control-which-one-should-we-choose/ |access-date=4 April 2024 |website=GFG}}</ref>
===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 codebases 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 recentralized, 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 tracking system|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>
The developer creates a pull request to notify maintainers of a new change; a comment thread is associated with each pull request. This allows for [[Code review|focused discussion of code changes]]. Submitted pull requests are visible to anyone with repository access. A pull request can be accepted or rejected by maintainers.<ref>{{cite web|title=Using pull requests|url=https://help.github.com/articles/using-pull-requests/|publisher=GitHub|access-date=27 March 2016}}</ref>
Once the pull request is reviewed and approved, it is merged into the repository. Depending on the established workflow, the code may need to be tested before being included into official release. Therefore, some projects contain a special branch for merging untested pull requests.<ref name="ossw" /><ref>{{cite web|title=Making a Pull Request|url=https://www.atlassian.com/git/tutorials/making-a-pull-request|publisher=Atlassian|access-date=27 March 2016}}</ref> Other projects run an automated test suite on every pull request, using a [[continuous integration]] tool, and the reviewer checks that any new code has appropriate test coverage.
==History==
| |||