Versiebeheer in softwareprojecten. Als u de wijzigingen uit deze revisie terugdraait, worden deze wijzigingen ongedaan gemaakt

Ivan Nemyttsjenko, GitLab
Maak uw leven gemakkelijker door samen softwareproducten te ontwikkelen.

Alexander Makarchuk, qb
Het optimaliseren van teamontwikkeling.

Peter Urvaev, SimbirSoft
Tijdens de ontwikkeling verandert de projectcode actief. Tegelijkertijd is het noodzakelijk om bij te houden wat er al is gedaan en de acties van individuele deelnemers te coördineren om tegelijkertijd de code te wijzigen, zodat verbeteringen door projectdeelnemers rekening houden met alle eerder aangebrachte wijzigingen door andere deelnemers. Met een versiebeheersysteem kunt u dit proces automatiseren.

2. Welke factoren beïnvloeden de keuze voor een versiebeheersysteem?

Nikolaj Fetjoechin,MST
Ondersteunen van de kern van het versiebeheersysteem en de specifieke implementatie daarvan, het team hiermee vertrouwd maken. Meestal wordt één systeem voor alle projecten gebruikt. Uitzonderingen kunnen bijvoorbeeld klantwensen zijn.

Ivan Nemyttsjenko, GitLab
De populariteit van een bepaald systeem, waaruit al het andere voortvloeit: ondersteuning in applicaties en diensten, kwantiteit en kwaliteit van documentatie, beschikbaarheid van een expert ‘in de buurt’, etc.

Alexander Makarchuk, qb
In ons geval is de keuze gebaseerd op de populariteit van het versiebeheersysteem en het vaardigheidsniveau van de ontwikkelaars ermee.

Peter Urvaev, SimbirSoft
Allereerst komen de mogelijkheden van het versiebeheersysteem overeen met het door het team aangenomen ontwikkelingsproces. Ten tweede: met welk versiebeheersysteem werken projectdeelnemers het meest?

3. Hoe implementeer je het gebruik van versiebeheer in een team?

Nikolaj Fetjoechin,MST
Nu studeren zelfs moderne studenten er al mee af gemeenschappelijk begrip, waarvoor versiebeheersystemen nodig zijn, dus de kwestie van de implementatie is niet helemaal correct. Normaal gesproken beginnen alle projecten standaard met het maken van een repository. Als binnen algemeen geval, dan moet je met het team praten, uitzoeken waarom er geen versiebeheersysteem op het project is (af en toe zijn er verschillende zeer specifieke gevallen), en als de problemen overkomelijk zijn, dan een paar seminars binnen het team houden over een specifiek versiebeheersysteem (indien nodig) en aan de slag.

Ivan Nemyttsjenko, GitLab
Geef ze de kans om zonder versiebeheersysteem te werken, zodat ze alle pijn voelen. Geef ze dan een Git-spiekbriefje, en ze zullen alles zelf leren en implementeren. Maar dit is hoe je met schoolkinderen en studenten kunt werken. Volwassen ontwikkelaars hebben deze vraag meestal niet.

Alexander Makarchuk, qb
Langzaam maar zeker komt iedereen hier op zichzelf toe.

Peter Urvaev, SimbirSoft
In de meerderheid moderne projecten de noodzaak om een ​​versiebeheersysteem te gebruiken roept geen vragen op. Als je ermee leert werken, is het voldoende om het te configureren comfortabel werk en lees een korte lezing over de belangrijkste mogelijkheden van het gebruikte versiebeheersysteem, met gebruiksvoorbeelden.

4. Wat maakte Git tot de standaard in de wereld van versiebeheersystemen? Zal iemand hem uit zijn leidende positie kunnen verdringen?

Nikolaj Fetjoechin,MST
Git bevatte oorspronkelijk verschillende nuttige zaken, zoals lokale commits, en ook opgelost groot aantal problemen met het samenvoegen van branches, die rijk waren aan de vorige trendsetter - Subversion (SVN). Vanaf het allereerste begin vocht het om populariteit met Mercurial (Hg), dat in sommige opzichten eenvoudiger is, maar uiteindelijk de leiding nam.

Ivan Nemyttsjenko, GitLab
Dankzij het feit dat Linus Torvalds viel het probleem van de gedistribueerde ontwikkeling van de rechterkant aan, rekening houdend met de tekortkomingen van voorgaande systemen. Beweging? Waarom?

Alexander Makarchuk, qb
Dankzij het feit dat Git geweldig is. Niemand zal hem voor een hele lange tijd verdringen.

Peter Urvaev, SimbirSoft
Het belangrijkste voordeel van Git is de ontwikkeling van tools om ermee te werken en de mogelijkheid om daarin de resultaten van het werk aan verschillende parallelle open taken op te slaan, zodat tussenresultaten elkaar niet beïnvloeden, en tegelijkertijd de uiteindelijke resultaten kunnen vrij eenvoudig gecombineerd worden tot één definitieve versie van de applicatie. Ook werd een belangrijke rol gespeeld in de universele populariteit van Git in de CVS-wereld door de GitHub-bron, die duizenden repository's in verschillende talen host.

5. Wat vinden ontwikkelaars niet leuk aan Git? Waarom kiezen sommige mensen voor andere, minder populaire oplossingen?

Nikolaj Fetjoechin,MST
Het enige belangrijke nadeel van Git voor ons zijn enkele problemen met het bijhouden van wijzigingen: branches kunnen worden verwijderd en er kan alleen een merge-commit overblijven. Dit komt grotendeels door het feit dat Git branches heeft die aan commits zijn gekoppeld. Git heeft ook een steilere leercurve dan de eerder genoemde Mercurial of Subversion.

Alexander Makarchuk, qb
Binnen de kaders van onze taken is iedereen tevreden.

Peter Urvaev, SimbirSoft
Git is best handig, maar vereist leren (voor degenen die het nog niet kennen) en actieve stappen om ernaar over te schakelen, dus sommige teams blijven liever bij de versiebeheersystemen die ze gebruiken. Ook kan de keuze voor het versiebeheersysteem worden bepaald door de gebruikte ontwikkeltools.

6. Hoe gebruikelijk is het om versiebeheersystemen te gebruiken om andere bestanden dan alleen code te beheren?

Nikolaj Fetjoechin,MST
Momenteel overal. Hetzelfde cloud systemen leuk vinden Eén rit, Yandex.Disk, Dropbox en Google Drive Ze zijn gebaseerd op een ideologie die versiebeheersystemen repliceert.

In de praktijk is het gebruik van conventionele versiebeheersystemen voor het opslaan van documenten gebruikelijk, maar er ontstaan ​​niet al te vaak subtiliteiten bij het berekenen van wijzigingen, aangezien de meeste hedendaagse documentformaten binair zijn en hun wijzigingensets niet voor mensen leesbaar zijn.

Alexander Makarchuk, qb
Voortdurend gebruikt.

Peter Urvaev, SimbirSoft
Versiebeheersystemen zijn primair gericht op het werken met een groot aantal kleine bestanden, die voornamelijk bij de ontwikkeling worden gebruikt. Het gebruik van dergelijke systemen voor niet-tekstbestandsformaten (binair) is meestal niet effectief, en in sommige gevallen zelfs volkomen onmogelijk. Daarom worden ze meestal gebruikt om andere bestanden op te slaan. gespecialiseerde systemen, aangepast om met bepaalde gegevensformaten te werken.

Heeft u een geweldig nieuw bedrijfsidee met betrekking tot softwareontwikkeling?Je moet je technologisch ontwikkelen moeilijke beslissing? Of heeft u een groot team programmeurs die aan dezelfde taak werken? Onthoud dan deze drie woorden:versiebeheersysteem .

Versiebeheersysteem (cvs), 2017 - Vergelijk: Git, SVN, Mercurial

, of vc's- Dit zorgt ervoor dat een project niet uit elkaar valt als er veel mensen aan werken. Programmeurs, managers, copywriters kunnen ieder aan hun eigen stuk werken zonder elkaar te hinderen en zonder schade aan te richten die niet kan worden hersteld.

Mocht je nog niet bekend zijn met het conceptversiebeheersystemen, dan hier alles wordt heel duidelijk weergegeven.

Of bekijk de video van GitHub.

Welk versiebeheersysteem is geschikt voor uw project?

Om het maken van een keuze makkelijker te maken hebben wij een aantal populaire oplossingen met elkaar vergeleken.

Dit is een zeer gespecialiseerd technisch onderwerp. Wij hebben geprobeerd onze recensie voor iedereen begrijpelijk te maken. Maar als u geen programmeerervaring heeft, overleg dan eerst met uw ontwikkelingsafdeling voordat u beslissingen neemt.

Versiebeheersystemen, inclusief de bekende SVN (Subversion) en Git, zijn oorspronkelijk gemaakt om teams van ontwikkelaars aan samenwerkingsprojecten te laten werken zonder verwarring te creëren. In het besturingssysteem hoeft u niet zelfstandig codevertakkingen te volgen en de aantekeningen daarbij te bestuderen. In plaats daarvan wordt een centrale opslagplaats gebruikt waar alles georganiseerd en gestructureerd is. Het is handig om bestanden bij te werken, opmerkingen toe te voegen en zelfs projectvertakkingen samen te voegen.

Meningen over watversiebeheersysteemde beste varieert enorm, en dit leidt tot verhitte discussies onder programmeurs. Selecteren en studerenversiebeheersystemenBedenk voor uw project dat de voordelen van een bepaalde oplossing vaak subjectief zijn. Bijvoorbeeld de persoonlijke voorkeuren van de programmeur of bijvoorbeeld indicatoren zoals prestaties, mogelijkheden van IDE-plug-ins, enz.

Het belangrijkste verschil tussen versiebeheersystemen is of ze client-server of gedecentraliseerd (p2p) zijn. Hebben ze een centrale repository (server) waar de code vandaan wordt gehaald en waar deze wordt geretourneerd met aangebrachte wijzigingen? Of het is een kopie in lokale opslag, bijgewerkt via peers: een meer gedecentraliseerd netwerk dat wordt gebruikt voor synchronisatie, het delen van patches (wijzigingssets) en het onderhouden van de huidige code.

Het is ook de moeite waard om rekening te houden met de snelheid, functionaliteit en drempel voor toegang/beheersing van een specifiek onderdeelbesturingssystemen. Laten we eens kijken naar de meest voorkomendeversiebeheersystemenen de redenen waarom programmeurs bepaalde oplossingen verkiezen.

Gelijktijdig versiesysteem (CVS)

CVS verscheen in de jaren tachtig en is nog steeds populair onder ontwikkelaars commerciële producten, en van open-sourceontwikkelaars.

CVS verdeeld onder de voorwaardenGNU Open License Agreement en stelt u in staat om op te halen van de server de vereiste versie project-"uitchecken" (uittreksel) en stuur het vervolgens terug naar de server, "inchecken" (retour),met de aangebrachte wijzigingen.

Oorspronkelijk CVS is gemaakt om versieconflicten te voorkomen. Alle deelnemers kregen alleen de nieuwste versie van de code om mee te werken. Dit was het eerste versiecontrolesysteem. De gebruiker moest snel wijzigingen in de repository doorvoeren voordat anderen hem voor waren.

Nu CVS heeft ondersteuning voor het werken aan projecten met codevertakkingen. Dit resulteert in verschillende productopties met verschillende kenmerken, die later kunnen worden gecombineerd.

CVS-servers werk meestal onder Unix-beheer, Maar CVS -clients zijn ook beschikbaar in andere populaire besturingssystemen. CVS - “volwassen”, beproefdversiebeheersysteem. Het is nog steeds een open source-systeem, maar tegenwoordig worden er vrij zelden nieuwe functies toegevoegd.

Tegelijkertijd is CVSNT een versie die is opgedeeld in een afzonderlijk project CVS Voor Windows-servers, - breidt nu behoorlijk actief zijn functionaliteit uit.

Voordelen:

• Beproefde technologie die al tientallen jaren op de markt is.

Gebreken:

• Het hernoemen of verplaatsen van bestanden wordt niet weergegeven in de geschiedenis
• Beveiligingsrisico's verbonden aan symbolische koppelingen naar bestanden
• Geen ondersteuning voor atomaire operaties, wat kan leiden tot codecorruptie
• Operaties met vestigingen programmacode duur, zoals ditcontrolesysteemniet bedoeld voor langetermijnprojecten met codevertakkingen

Apache-subversie (SVN)

SVN is gemaakt als alternatief CVS om tekortkomingen te corrigeren CVS en tegelijkertijd zorgen voor een hoge compatibiliteit ermee.

Zoals CVS SVN is een gratis systeem versiebeheer met geopend broncode. Het enige verschil is dat het wordt gedistribueerd onder de Apache-licentie, en niet onderOpen licentieovereenkomst GNU.

Om de integriteit van de database te behouden, maakt SVN gebruik van zogenaamde atomaire operaties. Wanneer nieuwe versie Alle of geen van de oplossingen worden op het eindproduct toegepast. Zo wordt de code beschermd tegen chaotische gedeeltelijke bewerkingen die inconsistent met elkaar zijn en fouten veroorzaken.

Veel ontwikkelaars zijn overgestapt naarSVN omdat nieuwe technologie betere kansen geërfd CVS en breidde ze tegelijkertijd uit.

Terwijl ik bij CVS ben bewerkingen met codevertakkingen zijn duur en worden niet voorzien door de systeemarchitectuur die speciaal hiervoor is gemaakt; Dat wil zeggen, voor meer grote projecten met codevertakking en vele ontwikkelingsrichtingen.

De nadelen van SVN worden relatief genoemd lage snelheid en gebrek aan gedistribueerd versiebeheer. Gedistribueerd versiebeheer gebruikt een peer-to-peer-model in plaats van een gecentraliseerde server om softwarecode-updates op te slaan. En hoewel het peer-to-peer-model beter werkt in open source-projecten, is het in andere gevallen niet ideaal. Het nadeel van de server-side aanpak is dat wanneer de server crasht, clients geen toegang hebben tot de code.

Voordelen:

• Systeemgebaseerd CVS
• Maakt atomaire operaties mogelijk
• Codevertakkingsoperaties zijn goedkoper
• Brede selectie van IDE-plug-ins
• Maakt geen gebruik van een peer-to-peer-model

Gebreken:

• Fouten blijven bestaan gerelateerd aan het hernoemen van bestanden en mappen
• Onbevredigende reeks opdrachten voor het werken met de repository
• Relatief lage snelheid

Git

Dit systeem is gemaakt om de ontwikkeling te beheren Linux-kernels en hanteert een aanpak die totaal anders is dan CVS en SVN.

De basis Git Er werden concepten vastgelegd om een ​​snellere distributie te creërenversiebeheersysteem, in tegenstelling tot de regels en oplossingen die daarin worden gebruikt CVS . Omdat Git primair voor Linux is ontwikkeld, draait het het snelst op dit besturingssysteem.

Git werkt ook op Unix-achtige systemen (zoals MacOS), en om op te draaien Windows-platform mSysGit-pakket wordt gebruikt.

De programmacode is mogelijk niet beschikbaar als u een computer zonder repository gebruikt. Er zijn oplossingen voor dit probleem, en sommige ontwikkelaars zijn van mening dat de snelheid van Git een eerlijke prijs is om voor het ongemak te betalen.

Git heeft ook veel tools om door je wijzigingsgeschiedenis te navigeren. Elke werkkopie van de broncode bevat de volledige ontwikkelingsgeschiedenis, wat uiterst handig is bij het programmeren zonder internetverbinding.

Voordelen:

• Geweldig voor degenen die haten CVS/SVN
• Aanzienlijke prestatieverbetering
• Goedkope operaties met codevertakkingen
• Volledige ontwikkelingsgeschiedenis offline beschikbaar
• Gedistribueerd, peer-to-peer-model

Gebreken:

• Hoge toegangsdrempel (leren) voor degenen die eerder SVN hebben gebruikt
• Beperkt Windows-ondersteuning(vergeleken met Linux)

Mercuriaal

Mercuriaal werd tegelijkertijd met Git uitgebracht. Dit is ook zo gedistribueerd versiebeheersysteem.

Mercurial is gemaakt als alternatief voor Git voor het ontwikkelen van Linux-kernelmodules. Maar sinds we voor Git hebben gekozen, wordt Mercurial minder gebruikt. Veel toonaangevende ontwikkelaars werken echter bijvoorbeeld met dit systeemOpenOffice.org .

Het versiebeheersysteem van Mercurial is anders dan andereversiebeheersystemenomdat het voornamelijk in Python is geschreven (niet in C). Sommige onderdelen zijn echter geïmplementeerd als uitbreidingsmodules in C.

Omdat het systeem decentraal is en in Python geschreven, zijn veel Python-programmeurs geneigd over te stappen naar Mercurial.

Gebruikers merken op dat Mercurial een aantal kenmerken van SVN behoudt, terwijl het een gedistribueerd systeem is, en vanwege deze gelijkenis heeft het een lagere toetredingsdrempel voor degenen die al bekend zijn met SVN. Ook is de documentatie van Mercurial completer, waardoor je sneller aan de verschillen gewend raakt.

Een van de belangrijke nadelen van Mercurial is dat het, in tegenstelling tot Git, twee bovenliggende takken niet kan samenvoegen, omdat Mercurial een plug-insysteem gebruikt in plaats van scriptondersteuning. Dit is geweldig voor sommige programmeurs, maar velen willen de kracht van Git niet opgeven.

Voordelen:

• Gemakkelijker te leren vergeleken met Git
• Gedetailleerde documentatie
• Gedistribueerd modelversiebeheersystemen

Gebreken:

• Er is geen optie om twee bovenliggende takken samen te voegen
• Plug-ins gebruiken in plaats van scripts
• Minder mogelijkheden voor niet-standaard oplossingen

WelkeVersiebeheer werkt bij mij?

In de meeste gevallen gebruiken ontwikkelaars CVS omdat het voor hen vertrouwder is. Als een team al aan een project werkt, dan is er het vooruitzicht om alle ontwikkelingen over te dragen aan een andercontrolesysteemergens niet inspirerend. Als ze het systeem zouden moeten veranderen, zouden ze hoogstwaarschijnlijk overstappen naar SVN.

CVS heeft al de status van ‘volwassen technologie’ bereikt, wat betekent dat er niet langer radicaal nieuwe functies en oplossingen in zullen voorkomen. Het momentum van de gewoonte gaat verloren als mensen naar SVN verhuizen. Dit betekent dat CVS langzamerhand tot het verleden behoort.

Tegenwoordig heeft SVN de palmares onder de serverserversversiebeheersystemen. Het omvat voordelen CVS en overtreft ze. Als we het hebben over prevalentie, zul je waarschijnlijk vaker voorkomen CVS of SVN dan met Git of Mercurial. Kennis van één servertechnologie zal dus, hoewel niet essentieel, uw overstap vergemakkelijken.

Dankzij wijdverbreid gebruik en door de volwassenheid van de technologie beschikt SVN over een grote kennisbasis, waardoor gebruikers gemakkelijk hulp kunnen krijgen.

Git is duidelijk sneller dan zijn concurrenten. Voor projecten die zijn gemaakt voor gedistribueerdversiebeheersystemen, dit is een duidelijke verbetering.

Een belangrijk nadeel van Git is dat het soms moeilijk is om de nuances van hoe het werkt uit te leggen.besturingssystemen, en dit vertraagt ​​de workflow terwijl programmeurs eraan wennen. Zodra de ‘toegangsdrempel’ echter is overwonnen, neemt de productiviteit toe en zal het gemak van het beheren van codevertakkingen de bestede tijd volledig terugbetalen.

Voor degenen die Git haten (en het heeft zijn tegenstanders onder ontwikkelaars): Mercurial is een compromis tussen SVN en Git. Dit systeem wordt in veel bekende projecten gebruikt en beschikt bovendien over goede documentatie.

Compatibel met Windows-versie Git is ook bezig om net zo snel te worden als de Linux-versie, dus het kan voor jou relevant zijn, zelfs als je niet op Linux ontwikkelt.

Om te begrijpen welke het beste bij u past, moet u rekening houden met de kenmerken van het project en uw team. Praat met de ontwikkelaars!

Als een project één enkele broncodeboom vereist waaraan een kleine groep programmeurs zal werken, dan is SVN uw optie. Het is betrouwbaar en speciaal ontworpen voor dergelijke gevallen.

Als u een open-sourceproject lanceert, waarop u verschillende tijden meerdere programmeurs zullen werken of, als dit wordt verwacht constante update code en kies vervolgens Git. Het snelheids- en bronboombeheer is hier veel beter dan in SVN.

Als je op een kruispunt staat of de manier waarop SVN of Git werken gewoon niet leuk vindt, dan is Mercurial iets voor jou.

Al deze systemen zijn volledig functioneel. En ook gratis. Ze worden gebruikt om te creëren software, sites en zelfs besturingssystemen die u gebruikt en waarmee u bekend bent.

Bepaal eerst of de een of de ander geschikt iscontrolesysteemversies voor uw bedrijf, en zorg er vervolgens – net zo belangrijk – voor dat deze keuze programmeurs niet woedend maakt.

Aan de slag met SVN

Als je nog nooit met SVN of Git hebt gewerkt en geen idee hebt hoe je moet beginnen, dan is dit de oplossinghostingoplossing gecombineerd met grafische interface zal u helpen er snel aan te wennen.

Zoals in de meeste gevallen is het belangrijkste om aan de slag te gaan, en dan zal het begrip komen. Het bedienen van een versiebeheersysteem lijkt sterk op het werken met bestanden op een server met behulp van een FTP-client.

OPMERKING:Er zijn veel hostingoplossingen voorversiebeheersystemen, inclusief gratis proefperiode. Op basis daarvan kunt u uw eerste repository maken (een plaats voor samenwerking met codebestanden) volledig gratis. Hier zijn enkele van deze diensten:

SVN- en GIT-hosting

Het maken van de eerste opslagplaats

Nadat u een account heeft aangemaakt, moet u voor elk platform afzonderlijk een repository aanmaken. Meestal ziet het er zo uit:

• Log in op uw account, klik op uw projecten.
• Een project aanmaken:

• Voer in de regel "Een nieuw project maken" de naam van uw project in
• Klik op de knop ‘Project aanmaken’

• SVN-verbinding:

• Nadat u het project heeft aangemaakt, selecteert u het tabblad “Bronbeheer” (broncodeversies)
• Klik op de link “Broncontrole inschakelen”
• Geef de opslagplaats een naam
• Klik op "Opslaan"

Grafische klanten SVN en GIT

Dus de repository is gemaakt. Nu willen we dat alles er eenvoudig en duidelijk in wordt weergegeven. Om dit te doen heb je een GUI nodig.

— handig programma om mee te werkenversiebeheersystemenV Microsoft Windows en misschien wel de beste Apache Subversion-client die beschikbaar is. TortoiseSVN is geïmplementeerd als een Windows shell-extensie, waardoor het eenvoudig te integreren is browser. Het is ook een open source-programma met 34 taalpakketten beschikbaar

SmartGit

– Git grafische client ( Open bron gedistribueerdversiebeheersysteem). Werkt op Windows, Mac OS X en Linux.Licentiekosten - $ 39

De repository "uitchecken" ("Afrekenen")

De klant is dus geselecteerd. Nu moet u een opslagplaats voor het besturingssysteem maken. Moet binnenkomenUw repository-URL, gebruikersnaam en wachtwoord.

De URL ziet er meestal als volgt uit:https://svn .hostnaam.com/svn/ > (je kunt https:// (SSL) gebruiken als je dat hebt betaalde rekening)

1. Ga naar hoofdmap, klik op de knop Uitchecken en maak een werkmap voor de klant. Nu kunt u er bestanden aan toevoegen.
2. Zodra de projectbestanden zijn uitgepakt, kunt u ze bewerken in een lokale map op uw computer.

Nadat u wijzigingen in de bestanden heeft aangebracht, klikt u op de knop Inchecken op de werkbalk om ze op te slaan. U kunt wijzigingen bekijken en er opmerkingen aan toevoegen - het is best wel wat goed idee, omdat je in de toekomst precies weet waar je aan hebt gewerkt, welke wijzigingen er zijn doorgevoerd en je andere projectdeelnemers op de hoogte houdt.

Uw klant moet ook de mogelijkheid bieden om op elk moment met revisies te gaan werken door het revisielogboek of de wijzigingsgeschiedenis te openen. Vervolgens kunt u, indien nodig, “teruggaan” naar vorige versie voor elk bestand afzonderlijk. Nu u bekend bent met de basisconcepten, de documentatie

Versiebeheersystemen registreren en slaan meerdere wijzigingen in bestanden op. Dankzij dit kunt u terugkeren naar bepaald punt geschiedenis van bestands- of projectwijzigingen. Sommige systemen, zoals Subversion, houden de geschiedenis van individuele bestanden bij. Anderen, zoals Git en Mercurial, houden de geschiedenis van hele repositories bij.

Versiebeheer is als een beveiligingssysteem. Als u wijzigingen hebt aangebracht die later problemen hebben veroorzaakt, kunt u het bestand of het hele project terugzetten naar een bepaald punt in plaats van helemaal opnieuw te beginnen.

Een van de meest gebruikte opties is lokaal versiebeheer. Daarom besteden de meeste gebruikers er eenvoudigweg geen aandacht aan, omdat het een van de vele functies van de applicatie is.

In elke toepassing wordt het tenminste geïmplementeerd basisniveau lokale controle versies, bestaande uit de functies “ongedaan maken” en “opnieuw uitvoeren”. Sommige programma's zoals Microsoft Office En Google-documenten, bevatten meer geavanceerde functies, zoals versievergelijking en commentaar.

Applicatieversiecontrolesystemen worden beperkt door de bestandstypen die ze ondersteunen en de hoeveelheid wijzigingsgeschiedenis die ze kunnen opslaan. Op zijn beurt autonome systemen versiebeheer kan zich op meer richten complexe functies, slaan oneindige versiegeschiedenissen op en zijn niet beperkt tot specifieke formaten. Hoewel sommige systemen daar meer geschikt voor zijn specifieke bestanden. Om deze reden zijn ze populairder bij het programmeren. Hoewel ze kunnen worden gebruikt om versies van elk bestand te beheren, van basic tekstdocumenten tot grote grafische bestanden.

Versiebeheersystemen zijn onderverdeeld in twee categorieën: gedistribueerd en gecentraliseerd. Elk heeft zijn eigen voor- en nadelen, waardoor ze ideaal zijn voor verschillende workflows. Elk type bevat er veel diverse systemen. De meest populaire versiebeheersystemen zijn Git, Subversion en Mercurial. Laten we eens kijken naar de belangrijkste verschillen tussen gedistribueerd en gecentraliseerd versiebeheer.

Gedistribueerd versiebeheer

Gedistribueerd versiebeheer wordt ook wel gedistribueerd revisiebeheer genoemd. Het is gebouwd op het principe van gelijkheid van knooppunten. Bovendien heeft elk peer-knooppunt zijn eigen kloon van de repository. Met deze aanpak wordt de geschiedenis van de codebasis gekopieerd, zodat eventuele fatale schade aan de originele, server-side repository volledig kan worden hersteld vanaf elk van de beschikbare klonen. In de standaardworkflow resulteren wijzigingen in de repository echter niet in volledige update opslagplaats. In plaats daarvan worden alleen wijzigingen aan peers weergegeven, zodat u snel bewerkingen kunt uitvoeren zonder dat u contact hoeft te maken met de server.

Gedistribueerd versiebeheer is populair dankzij systemen als Git en Mercurial. Ze worden veel gebruikt om samenwerking in open source-projecten te vergemakkelijken. Vanwege de aard van de opzet zorgt het klonen van de volledige projectcodebasis voor elk peer-systeem voor meer vrijheid als het gaat om workflows en samenwerking.

Gecentraliseerd versiebeheer

In tegenstelling tot gedistribueerd versiebeheer en lokaal versiebeheer, kunnen gegevens in gecentraliseerde versiebeheersystemen ( CVC), zoals Perforce en Subversion, worden opgeslagen in opslagplaatsen op de server. Dit betekent dat elk knooppunt bestanden controleert en wijzigingen doorvoert in een centrale database.

Het probleem is de beschikbaarheid van gegevens. Omdat de bestanden in een centrale opslag worden opgeslagen, kan er bij een crash van de server pas worden gewerkt als de server opnieuw is opgestart. Bovendien, als de server beschadigd is, dan bij gebrek aan up-to-date reservekopie alle gegevens kunnen volledig verloren gaan.

Het grote voordeel van dergelijke systemen is dat de gegevens op één plek worden opgeslagen. Dit vereenvoudigt het onderhoud en beperkt de toegang van de gebruiker.

Conclusie

Versiebeheer is handige manier het monitoren van wijzigingen in dossiers en projecten. Hoewel versiebeheersystemen voornamelijk op de markt worden gebracht als hulpmiddelen voor het beheren van softwareontwikkelingsprojecten, kunnen ze nuttig zijn voor het beheren van elk type bestand.

Vertaling van het artikel “Wat is versiebeheer” door het vriendelijke projectteam.

Goed slecht

Versiebeheersysteem(van het Engelse Version Control System - VCS of Revision Control System) - speciale software voor het werken met vaak veranderende informatie, waarmee u meerdere versies van hetzelfde document kunt opslaan en, indien nodig, kunt terugkeren naar meer eerdere versies, bepaal wie en wanneer deze of gene wijziging heeft aangebracht, en nog veel meer.

Dergelijke systemen worden het meest gebruikt bij de ontwikkeling van software voor het opslaan van bestanden van het programma dat wordt ontwikkeld.

Het komt vaak voor dat meerdere mensen tegelijkertijd aan hetzelfde project werken, en als twee mensen hetzelfde bestand wijzigen, kan een van hen per ongeluk de wijzigingen van de ander ongedaan maken. Versiebeheersystemen volgen dergelijke conflicten en bieden middelen om deze op te lossen. De meeste van deze systemen kunnen aangebrachte wijzigingen automatisch samenvoegen (samenvoegen). door verschillende ontwikkelaars. Een dergelijk automatisch samenvoegen van wijzigingen is echter doorgaans alleen mogelijk voor tekstbestanden en op voorwaarde dat verschillende (niet-overlappende) delen van het bestand zijn gewijzigd. Deze beperking is te wijten aan het feit dat de meeste versiebeheersystemen gericht zijn op het ondersteunen van het softwareontwikkelingsproces, en dat programmabroncodes worden opgeslagen in tekstbestanden. Als het automatisch samenvoegen mislukt, kan het systeem aanbieden het probleem handmatig op te lossen.

Sommige versiebeheersystemen bieden de mogelijkheid om een ​​bestand in de repository te vergrendelen. Door te vergrendelen wordt voorkomen dat andere gebruikers toegang krijgen werkkopie of verhindert dat de werkkopie van het bestand wordt gewijzigd (bijvoorbeeld door middel van bestandssysteem) en biedt dus alleen exclusieve toegang aan de gebruiker die met het document werkt.

De meeste versiebeheersystemen bieden de volgende functies:

• laat je creëren verschillende optieséén document (vertakking) met een gemeenschappelijke geschiedenis van veranderingen vóór het vertakkingspunt en met verschillende erna;
• het mogelijk maken om erachter te komen wie en wanneer een specifieke reeks regels in een bestand heeft toegevoegd of gewijzigd;
• een wijzigingslogboek bijhouden waarin gebruikers uitleg kunnen opschrijven over wat en waarom ze in een bepaalde versie zijn gewijzigd;
• de toegangsrechten van gebruikers beheren, waarbij het lezen of wijzigen van gegevens wordt toegestaan ​​of geweigerd, afhankelijk van wie om deze actie vraagt.

Elk versiebeheersysteem heeft zijn eigen versiebeheersysteem specifieke kenmerken in de reeks opdrachten, hoe gebruikers werken en beheer. De algemene werkwijze voor de meeste VCS'en is echter volledig stereotiep. Hierbij wordt ervan uitgegaan dat het project, wat het ook mag zijn, al bestaat en dat de repository ervan zich op de server bevindt waartoe de ontwikkelaar toegang krijgt.

Aan de slag met het systeem. De eerste stap die een ontwikkelaar moet nemen, is het ophalen van een werkkopie van het project, of van het gedeelte ervan waaraan moet worden gewerkt. Deze actie wordt uitgevoerd met behulp van de standaardversie checkout-opdracht (checkout of clone) of met behulp van speciaal elftal, die feitelijk dezelfde actie uitvoert. De ontwikkelaar specificeert de versie die standaard moet worden gekopieerd; meestal wordt de nieuwste versie (of degene die door de beheerder als hoofdversie is gekozen) gekopieerd.

Dagelijkse werkcyclus. De werkcyclus van een typische ontwikkelaar tijdens een werkdag ziet er als volgt uit:

• het bijwerken van de werkkopie: Naarmate er wijzigingen worden aangebracht in de hoofdversie van het project, wordt de werkkopie op de computer van de ontwikkelaar oud en neemt de discrepantie met de hoofdversie van het project toe. Dit vergroot het risico op conflicterende wijzigingen (zie hieronder) en wordt noodzakelijk om de werkkopie in een staat te houden die zo dicht mogelijk bij de huidige hoofdversieversie ligt, zodat de ontwikkelaar de werkkopie zo vaak mogelijk bijwerkt, wat wordt bepaald door de frequentie van wijzigingen afhankelijk van de ontwikkelingsactiviteit, het aantal ontwikkelaars en de tijd besteed aan elke update;
• projectwijziging: de ontwikkelaar wijzigt het project, wijzigt de bestanden die erin zijn opgenomen in de werkkopie in overeenstemming met de projectopdracht, dit werk wordt lokaal uitgevoerd en vereist geen oproepen naar de VCS-server;
• wijzigingen doorvoeren: Nadat de ontwikkelaar de volgende fase van het werk aan een taak heeft voltooid, commit hij zijn wijzigingen en brengt deze over naar de server (hetzij naar de hoofdtak, als het werk aan de taak volledig is voltooid, hetzij naar een afzonderlijke ontwikkelingstak voor deze taak).

VCS-basisprincipes

Invoering

Voordat u over een specifiek versiebeheersysteem praat, moet u begrijpen wat het is, wat het is en waarom ze überhaupt zijn verschenen. Deze lezing is bedoeld als een eerste kennismaking met versiebeheer en versiebeheersystemen. Eerst zal ik het hebben over de oorsprong van versiebeheertools, welke versiebeheersystemen momenteel populair zijn en wat de belangrijkste verschillen daartussen zijn.

Over versiebeheer

Wat is versiebeheer en waarom heb je het nodig?

Het is waarschijnlijk de moeite waard om te beginnen met de definitie van een versiebeheersysteem (VCS) - dit is een systeem dat wijzigingen in een of meer bestanden registreert, zodat het in de toekomst mogelijk is om terug te keren naar bepaalde oude versies van deze bestanden.

IN de laatste tijd bestanden zijn het eindresultaat voor veel beroepen (bijvoorbeeld schrijven, wetenschappelijke werken en natuurlijk softwareontwikkeling). Er wordt veel tijd en moeite gestoken in het ontwikkelen en onderhouden van deze bestanden, en niemand wil nog meer tijd en moeite besteden aan het herstellen van gegevens die verloren zijn gegaan als gevolg van eventuele wijzigingen.

Laten we ons voorstellen dat een programmeur een project ontwikkelt dat uit één klein bestand bestaat (het voorbeeld is trouwens vrij reëel, niet synthetisch, te vinden in echte leven). Nadat hij de eerste versie van het project heeft uitgebracht, staat hij voor een moeilijke keuze: het is noodzakelijk om de door gebruikers van de eerste versie gemelde problemen op te lossen en tegelijkertijd iets nieuws voor de tweede te ontwikkelen. Zelfs als u alleen maar de problemen hoeft op te lossen die zich voordoen, is de kans groot dat het project na enige wijziging niet meer werkt en moet u bepalen wat er is gewijzigd om het gemakkelijker te maken het probleem te lokaliseren. Het is ook raadzaam om een ​​soort logboek bij te houden van de aangebrachte wijzigingen en correcties, zodat u niet meerdere keren hetzelfde werk hoeft te doen.

In het eenvoudigste geval kan het bovenstaande probleem worden opgelost door meerdere kopieën van de bestanden op te slaan, bijvoorbeeld één voor het herstellen van fouten in de eerste versie van het project en een tweede voor nieuwe wijzigingen. Omdat de wijzigingen meestal niet erg groot zijn in vergelijking met de bestandsgrootte, is het mogelijk om alleen de gewijzigde regels op te slaan met behulp van het diff-hulpprogramma en ze later samen te voegen met het patch-hulpprogramma. Maar wat als het project uit enkele duizenden bestanden bestaat en er honderd mensen aan werken? Als we in dit geval de methode met opslag gebruiken aparte exemplaren bestanden (of zelfs alleen maar wijzigingen), dan loopt het project zeer snel vast. In de volgende lezingen zal ik als voorbeeld de broncodes van programma's gebruiken, maar in feite kan bijna elk type bestand onder versiebeheer worden geplaatst.

Als u een grafisch ontwerper of webontwerper bent en elke versie van een afbeelding of lay-out wilt opslaan - en dat zou u waarschijnlijk ook doen - dan is het gebruik van een versiebeheersysteem een ​​zeer verstandige beslissing. Valuta valuta maakt het mogelijk om te retourneren aparte bestanden Naar als voorheen, terug naar vorige staat het hele project, bekijk de veranderingen die zich in de loop van de tijd hebben voorgedaan, bepaal wie de laatste was die wijzigingen aanbracht in een module die plotseling niet meer werkte, wie en wanneer er een fout in de code werd geïntroduceerd, en nog veel meer. Als u tijdens het gebruik van VCS alles verpest of bestanden kwijtraakt, kan alles over het algemeen eenvoudig worden hersteld. Bovendien zal de overhead voor alles wat u krijgt erg klein zijn.

Lokale versiebeheersystemen

Zoals eerder vermeld is een voorbeeld van een lokale VCS uiterst eenvoudig: veel mensen geven er de voorkeur aan versies te controleren door eenvoudigweg bestanden naar een andere map te kopiëren (meestal door de huidige datum aan de mapnaam toe te voegen). Deze aanpak is heel gebruikelijk omdat ze eenvoudig is, maar mislukt ook vaker. Het is heel gemakkelijk om te vergeten dat u zich in de verkeerde map bevindt en per ongeluk het verkeerde bestand wijzigt, of bestanden naar de verkeerde plaats kopieert en de bestanden overschrijft die u nodig hebt. Om dit probleem op te lossen, hebben programmeurs al lang lokale VCS ontwikkeld met een eenvoudige database waarin alle wijzigingen in de benodigde bestanden worden opgeslagen

Een van de populairste VCS'en van dit type is RCS (Revision Control System), dat nog steeds op veel computers is geïnstalleerd. Zelfs in een moderne operatiekamer Mac-systeem Het OS X rcs-hulpprogramma wordt samen met Developer Tools geïnstalleerd. RCS werd begin jaren tachtig ontwikkeld door Walter F. Tichy. Met het systeem kunt u versies van slechts één bestand opslaan, zodat u meerdere bestanden handmatig moet beheren. Voor elk bestand onder systeembeheer wordt versie-informatie opgeslagen in speciaal bestand met de naam van het originele bestand waaraan aan het einde de tekens ",v" worden toegevoegd. Voor het bestand file.txt worden de versies bijvoorbeeld opgeslagen in het bestand file.txt,v. Dit hulpprogramma is gebaseerd op het werken met sets patches tussen paren versies (een patch is een bestand dat het verschil tussen de bestanden beschrijft). Hierdoor kunt u elk bestand op elk moment opnieuw maken, waarbij u de patches opeenvolgend toepast. Het systeem gebruikt het diff-hulpprogramma om versies op te slaan. Hoewel RCS voldoet minimale vereisten Wat betreft het versiebeheersysteem heeft het de volgende belangrijke nadelen, die ook een stimulans vormden om het volgende systeem in kwestie te creëren:

• Werk met slechts één bestand, elk bestand moet afzonderlijk worden beheerd;
• Een lastig mechanisme voor meerdere gebruikers om tegelijkertijd met het systeem te werken; de opslag wordt eenvoudigweg geblokkeerd totdat de gebruiker die deze heeft geblokkeerd deze ontgrendelt;
• Niemand bevrijdt u van back-ups; u loopt het risico alles te verliezen.

Gecentraliseerde versiebeheersystemen

De volgende grote uitdaging was de noodzaak om samen te werken met ontwikkelaars op andere computers. Om dit op te lossen zijn er gecentraliseerde versiebeheersystemen (CVCS) gemaakt. Dergelijke systemen, zoals CVS, Subversion en Perforce, hebben een centrale server die alle bestanden onder versiebeheer opslaat, en een aantal clients die daarvan kopieën van de bestanden ontvangen. Dit is al jaren de standaard voor versiebeheersystemen.

Deze aanpak heeft veel voordelen, vooral ten opzichte van lokale SLE. Zo weet iedereen wie wat doet in het project. Beheerders hebben duidelijke controle over wie wat kan doen, en het beheer van CSKV is natuurlijk veel eenvoudiger lokale databases op elke cliënt. Er kleven echter een aantal ernstige nadelen aan deze aanpak. Het meest voor de hand liggende is dat de gecentraliseerde server het zwakke punt van het hele systeem is. Als de server een uur lang uitvalt, kunnen ontwikkelaars een uur lang niet communiceren en kan niemand een nieuwe versie van hun werk opslaan. Als de schijf met de centrale database beschadigd is en er geen reservekopie is, verliest u absoluut alles: de hele geschiedenis van het project, met de mogelijke uitzondering van verschillende werkende versies die zijn opgeslagen op de werkmachines van de gebruikers.

CVS

CVS (Concurrent Versions System) is nog steeds het meest gebruikte systeem, maar verliest snel zijn populariteit vanwege tekortkomingen die ik hieronder zal bespreken. Dick Grune ontwikkelde CVS halverwege de jaren tachtig. Om individuele bestanden op te slaan, gebruikt CVS (evenals RCS) bestanden in het RCS-formaat, maar u kunt ook groepen bestanden in mappen beheren. CVS maakt tevens gebruik van een client-server-architectuur waarbij alle versie-informatie op de server wordt opgeslagen. Door gebruik te maken van een client-server-architectuur kan CVS zelfs worden gebruikt door geografisch verspreide teams van gebruikers, waarbij elke gebruiker zijn eigen werkmap heeft met een kopie van het project. Zoals de naam al doet vermoeden, kunnen gebruikers het systeem delen.

Mogelijke conflicten bij het wijzigen van hetzelfde bestand worden opgelost doordat het systeem alleen wijzigingen toestaat nieuwste versie bestand. Daarom wordt het altijd aanbevolen om uw werkkopie van de bestanden bij te werken voordat u uw wijzigingen uploadt, in geval van mogelijk conflicterende wijzigingen. Bij het updaten brengt het systeem automatisch wijzigingen aan in de werkkopie en alleen in het geval van conflicterende wijzigingen in een van de bestandslocaties zijn vereist handmatige correctie plaatsen van conflict.

Met CVS kunt u ook meerdere ontwikkelingslijnen voor een project onderhouden met behulp van ontwikkelingstakken. Zo kunt u, zoals hierboven vermeld, fouten in de eerste versie van het project corrigeren en tegelijkertijd nieuwe functionaliteit ontwikkelen.

CVS werd door een groot aantal projecten gebruikt, maar uiteraard was het niet zonder tekortkomingen, wat later leidde tot de verschijning van het volgende systeem dat werd overwogen. Laten we eens kijken naar de belangrijkste nadelen:

• Omdat versies worden opgeslagen in RCS-bestanden, is het niet mogelijk om directoryversies op te slaan. Standaard methode om dit obstakel te omzeilen, is het opslaan van een bestand (bijvoorbeeld README.txt) in een map;
• Het verplaatsen of hernoemen van bestanden is niet onderworpen aan versiebeheer. De standaardmanier om dit te doen is door eerst het bestand te kopiëren, het oude te verwijderen met behulp van de opdracht cvs remove en het vervolgens toe te voegen met de nieuwe naam met behulp van de opdracht cvs add;

Subversie

Subversion (SVN) is in 2000 ontwikkeld op initiatief van CollabNet. SVN werd oorspronkelijk ontwikkeld als een “betere CVS” en het belangrijkste doel van de ontwikkelaars was het corrigeren van fouten in het CVS-ontwerp met behoud van een vergelijkbare interface. SVN maakt, net als CVS, gebruik van een client-server-architectuur. De belangrijkste veranderingen ten opzichte van CVS zijn onder meer:

• Atomaire veranderingen (commit). Als de verwerking van de commit wordt onderbroken, worden er geen wijzigingen aangebracht.
• Door bestanden te hernoemen, kopiëren en verplaatsen blijft de volledige geschiedenis van wijzigingen behouden.
• Telefoonboeken, symbolische verbanden en metadata zijn onderworpen aan versiebeheer.
• Efficiënte opslag van wisselgeld voor binaire bestanden.

Gedistribueerde versiebeheersystemen

En in deze situatie komen gedistribueerde versiecontrolesystemen (DVCS) in beeld. In systemen als Git, Mercurial, Bazaar of Darcs checken klanten niet alleen de nieuwste versies van bestanden, maar kopiëren ze de hele repository. Daarom kan, in het geval dat de server waar het werk doorheen ging “sterft”, elke clientrepository terug naar de server worden gekopieerd om de database te herstellen. Elke keer dat een klant een nieuwe versie van bestanden ophaalt, maakt hij deze voor zichzelf volledige kopie alle gegevens.

Bovendien kunt u met de meeste van deze systemen met meerdere externe repository's werken, zodat u er tegelijkertijd op verschillende manieren mee kunt werken verschillende groepen mensen binnen één project. Zo kunt u in één project tegelijkertijd verschillende soorten werkprocessen uitvoeren, wat onmogelijk is in gecentraliseerde systemen.

Waarom zijn gedistribueerde systemen nodig?

Zoals de naam al doet vermoeden, is een van de belangrijkste ideeën van gedistribueerde systemen de afwezigheid van een duidelijk aangewezen centrale versieopslag: een repository. In het geval van gedistribueerde systemen kan een reeks versies geheel of gedeeltelijk worden gedistribueerd tussen verschillende repository's, inclusief externe repository's. Dit model past perfect in het werk van gedistribueerde teams, bijvoorbeeld een team van ontwikkelaars verspreid over de hele wereld die aan hetzelfde open source-project werken. De ontwikkelaar van zo’n team kan alle versie-informatie downloaden en vervolgens alleen op de lokale machine werken. Zodra het resultaat van een van de werkfasen is bereikt, kunnen de wijzigingen worden geüpload naar een van de centrale opslagplaatsen of worden gepubliceerd voor weergave op de website van de ontwikkelaar, of in mailinglijst. Andere projectdeelnemers kunnen op hun beurt hun exemplaar van de versierepository bijwerken met nieuwe wijzigingen, of de gepubliceerde wijzigingen uitproberen op een afzonderlijke testontwikkelingstak. Helaas kan het ontbreken van één centrale repository zonder een goede projectorganisatie een nadeel zijn van gedistribueerde systemen. Als er in het geval van gecentraliseerde systemen altijd één gemeenschappelijke repository is waar u de nieuwste versie van het project kunt krijgen, dan moet u in het geval van gedistribueerde systemen organisatorisch beslissen welke van de projecttakken de belangrijkste zal zijn. Waarom zou een gedistribueerd versiebeheersysteem interessant zijn voor iemand die al een gecentraliseerd systeem gebruikt, zoals Subversion? Bij elke taak hoort het nemen van beslissingen, en in de meeste gevallen is het nodig om verschillende opties uit te proberen: bij het werken met versiebeheersystemen moet u rekening houden verschillende opties en werken aan grote veranderingen zijn ontwikkelingstakken. Hoewel dit een redelijk natuurlijk concept is, is het niet eenvoudig te gebruiken in Subversion. Bovendien wordt alles ingewikkelder in het geval van meerdere opeenvolgende samenvoegingen van de ene vertakking naar de andere - in dit geval moet u de begin- en eindversies van elke wijziging nauwkeurig aangeven om conflicten en fouten te voorkomen. Voor gedistribueerde versiebeheersystemen zijn ontwikkelingsvertakkingen een van de fundamentele concepten - in de meeste gevallen is elke kopie van een versiearchief een ontwikkelingsvertakking. Het mechanisme voor het samenvoegen van veranderingen van de ene tak naar de andere in het geval van gedistribueerde systemen is dus een van de belangrijkste, waardoor gebruikers minder moeite hoeven te doen bij het gebruik van het systeem.

Korte beschrijving van populaire gedistribueerde SUV's

• Git is een gedistribueerd versiebeheersysteem ontwikkeld door Linus Torvalds. Aanvankelijk was Git bedoeld voor gebruik in het Linux-kernelontwikkelingsproces, maar later werd het in veel andere projecten gebruikt, zoals bijvoorbeeld X.org en Ruby on Rails, Drupal. Op op dit moment Git is het snelst gedistribueerde systeem dat gebruik maakt van de meest compacte revisieopslag. Maar tegelijkertijd kan de Git-interface voor gebruikers die bijvoorbeeld migreren vanuit Subversion ingewikkeld lijken;
• Mercurial is een gedistribueerd systeem waarin is geschreven Python-taal met verschillende extensies in C. Projecten die Mercurial gebruiken zijn onder meer Mozilla en MoinMoin.
• Bazaar is een systeem ontwikkeld door Canonical, bekend om zijn Ubuntu-distributie en de website https://launchpad.net/. Het systeem is voornamelijk geschreven in Python en wordt gebruikt door projecten als MySQL.
• Codeville is een gedistribueerd systeem geschreven in Python dat een innovatief algoritme gebruikt voor het combineren van wijzigingen (samenvoegen). Het systeem wordt bijvoorbeeld gebruikt bij de ontwikkeling oorspronkelijke opdrachtgever BitTorrent.
• Darcs is een gedistribueerd versiebeheersysteem geschreven in Haskell en wordt bijvoorbeeld gebruikt door het Buildbot-project.
• Monotone is een systeem geschreven in C++ en gebruikt SQLite als revisieopslag.