Gedistribueerd broncodebeheer begrijpen
In de loop van de tijd zijn zogenaamde 'gedistribueerde' broncodebeheer- of versiebeheersystemen (DVCS voor kort) het belangrijkste geworden.
De drie populairste zijn Git, Mercurial en Bazaar. Deze systemen zijn niet noodzakelijkerwijs afhankelijk van een centrale server om alle versies van de bestanden van een project op te slaan. In plaats daarvan kloont elke ontwikkelaar een opslagplaatskopie en heeft de volledige geschiedenis van het project in de lokale opslag. Deze kopie (of 'clone') bevat alle oorspronkelijke metagegevens.
Deze methode klinkt mogelijk verspilling, maar het is geen probleem in de praktijk. De meeste programmeerprojecten bestaan voornamelijk uit tekstbestanden zonder opmaak (misschien een paar afbeeldingen).
De schijfruimte is zo goedkoop dat het opslaan van veel kopieën van een bestand geen merkbare deuk in een lokale opslagruimte maakt. Moderne systemen comprimeren ook de bestanden om nog minder ruimte te gebruiken; Objecten (en delta's) worden bijvoorbeeld gecomprimeerd opgeslagen en tekstbestanden die worden gebruikt in het programmeren comprimeren bron (ongeveer 60% van de oorspronkelijke grootte, of 40% vermindering van de grootte van compressie).
Het ophalen van nieuwe wijzigingen uit een opslagplaats wordt 'pulling' genoemd. Het verplaatsen van uw wijzigingen naar een opslagplaats wordt 'pushen' genoemd. U verplaatst wijzigingensets (wijzigingen in bestandsgroepen als coherente gehelen), geen diffs met één bestand.
Een veelvoorkomende misvatting over gedistribueerde versiebeheersystemen is dat er geen centrale projectopslagplaats kan zijn. Het is niet waar. Niets voorkomt dat u zegt: 'dit exemplaar van het project is de gezaghebbende'.
Dit betekent dat in plaats van een centrale opslagplaats die is vereist voor uw hulpprogramma's, deze nu optioneel is.
Voordelen van gecentraliseerd broncodebeheer
Het klonen van een hele opslagplaats biedt gedistribueerde hulpprogramma's voor broncodebeheer verschillende voordelen ten opzichte van gecentraliseerde systemen:
- Het uitvoeren van andere acties dan het pushen en ophalen van wijzigingensets is snel omdat het hulpprogramma alleen toegang nodig heeft tot de lokale opslag, niet tot een externe server.
- Het doorvoeren van nieuwe wijzigingensets kan lokaal worden uitgevoerd zonder dat iemand anders ze ziet. Zodra u een groep wijzigingensets klaar hebt, kunt u ze allemaal tegelijk pushen.
- Alles behalve pushen en ophalen kan zonder internetverbinding. U kunt dus op een vliegtuig werken en u wordt niet gedwongen om verschillende bugfixes door te voeren als één grote wijzigingenset.
- Omdat elke programmeur een volledige kopie van de projectopslagplaats heeft, kunnen ze wijzigingen delen met één of twee andere personen om feedback te krijgen voordat de wijzigingen aan iedereen worden weergegeven.
Nadelen vergeleken met gecentraliseerd broncodebeheer
Er zijn bijna geen nadelen voor het gebruik van een gedistribueerd broncodebeheersysteem via een gecentraliseerd systeem.
Gedistribueerde systemen verhinderen niet dat u één centrale opslagplaats hebt; ze bieden meer opties.
Er zijn slechts twee belangrijke inherente nadelen voor het gebruik van een gedistribueerd systeem:
- Als uw project veel grote, binaire bestanden bevat die niet efficiënt kunnen worden gecomprimeerd, kan de ruimte die nodig is om alle versies van deze bestanden op te slaan snel accumuleren.
- Als uw project een lange geschiedenis heeft (50.000 wijzigingensets of meer), kan het downloaden van de hele geschiedenis een onpraktische hoeveelheid tijd en schijfruimte in beslag nemen.