Software voor versiebeheer. Overzicht van het versiebeheersysteem

RCS (Revision Control System) is begin jaren tachtig ontwikkeld door Walter F. Tichy. Met het systeem kunt u versies van slechts één bestand opslaan, dus u moet meerdere bestanden handmatig beheren. Voor elk bestand dat door het systeem wordt beheerd, wordt versie-informatie opgeslagen in een speciaal bestand met de naam van het oorspronkelijke bestand waaraan de tekens ", v" aan het einde worden toegevoegd. Voor file.txt worden versies bijvoorbeeld opgeslagen in file.txt, v. Het systeem gebruikt het diff-hulpprogramma om versies op te slaan, dat wil zeggen dat alleen wijzigingen tussen versies worden opgeslagen.

Overweeg een voorbeeldsessie met RCS (het $ -teken geeft hierna een uitnodiging voor het besturingssysteem aan). Wanneer we het bestand onder RCS-controle willen plaatsen, gebruiken we het ci-commando (vanaf inchecken, registreren):

   $ ci file.txt

Met deze opdracht wordt het bestand file.txt, v gemaakt en wordt het oorspronkelijke bestand file.txt verwijderd (als u niet wordt verteld dat dit niet mag). Deze opdracht vraagt \u200b\u200book om een \u200b\u200bbeschrijving van alle opgeslagen versies. Omdat het bronbestand door het systeem is verwijderd, moeten we het opnieuw aanvragen om wijzigingen aan te brengen. Om dit te doen, gebruiken we het co-commando (van uitchecken, controle):

   $ co file.txt

Deze opdracht haalt de nieuwste versie van ons bestand uit file.txt, v. Nu kunnen we het bestand file.txt bewerken en nadat we de wijzigingen hebben voltooid, voert u het ci-commando opnieuw uit om de nieuwe gewijzigde versie van het bestand op te slaan:

   $ ci file.txt

Wanneer deze opdracht wordt uitgevoerd, zal het systeem ons om een \u200b\u200bbeschrijving van de wijzigingen vragen en vervolgens de nieuwe versie van het bestand opslaan.

Hoewel RCS voldoet aan de minimumvereisten voor een versiebeheersysteem, heeft het de volgende belangrijkste nadelen, die ook een stimulans vormden voor de oprichting van het volgende beschouwde systeem:

• Werk met slechts één bestand, elk bestand moet afzonderlijk worden beheerd;
• Een onhandig mechanisme voor gelijktijdig werk van meerdere gebruikers met het systeem, de opslag wordt eenvoudig geblokkeerd totdat de gebruiker het blokkeert en het ontgrendelt;

CVS

CVS (Concurrent Versions System) is nog steeds het meest gebruikte systeem, maar verliest snel aan populariteit vanwege gebreken die ik hieronder zal bespreken. Midden jaren tachtig ontwikkelde Dick Grune CVS. Om individuele bestanden op te slaan, gebruikt CVS (evenals RCS) bestanden in het RCS-formaat, maar stelt u in staat om groepen bestanden in mappen te beheren. CVS maakt ook gebruik van een client-serverarchitectuur waarin alle versie-informatie op de server is opgeslagen. Door client-serverarchitectuur te gebruiken, kan CVS zelfs worden gebruikt door geografisch verspreide gebruikersteams, waarbij elke gebruiker zijn eigen werkmap heeft met een kopie van het project.

Zoals de naam al aangeeft, kunnen gebruikers het systeem delen. Mogelijke conflicten bij het wijzigen van hetzelfde bestand worden opgelost doordat u met het systeem alleen wijzigingen kunt aanbrengen in de nieuwste versie van het bestand. Daarom wordt het altijd aanbevolen om uw werkkopie van bestanden bij te werken in geval van mogelijke tegenstrijdige wijzigingen voordat u uw wijzigingen uploadt. Bij het bijwerken brengt het systeem automatisch wijzigingen aan in de werkkopie en alleen in het geval van tegenstrijdige wijzigingen in een van de bestandslocaties is handmatige correctie van de conflictlocatie vereist.

CVS stelt je ook in staat om verschillende lijnen van projectontwikkeling te leiden met behulp van de takken van ontwikkeling. Zo kunt u, zoals hierboven vermeld, fouten in de eerste versie van het project corrigeren en tegelijkertijd nieuwe functionaliteit ontwikkelen.

Overweeg een kleine voorbeeldsessie met CVS. Allereerst moet je het project in CVS importeren, dit doe je met de importopdracht:

   $ cd een-project $ cvs import -m "Nieuw project" pad-in-repository niets start

Hier kunt u met de optie -m een \u200b\u200bbeschrijving van wijzigingen direct op de opdrachtregel specificeren, en als u deze weglaat, wordt er een teksteditor aangeroepen. Vervolgens wordt het pad aangegeven waarlangs het project in de repository wordt opgeslagen (path-in-repository in ons geval) en daarna zijn er twee labels: het label van de ontwikkelaar (het kan handig zijn als CVS wordt gebruikt om te werken aan projecten die door iemand anders zijn ontwikkeld) en het label van het project.

Nadat we ons project naar de repository hebben geüpload, moeten we een nieuwe directory maken waarin de werkkopie van het project onder CVS-controle wordt geplaatst en het project laden met het afrekencommando (control) of in verkorte vorm co:

   $ cd some-working-dir $ cvs checkout path-in-repository

Voor de checkout-opdracht geven we het pad naar ons project aan in de repository die we hierboven hebben aangegeven in de importopdracht.

Nu kunnen we wijzigingen aanbrengen in het project en deze uploaden naar de repository met behulp van de opdracht commit (wijzigingen aanbrengen), of kortweg ci:

   $ cvs commit -m "Enkele wijzigingen"

Net als bij de importopdracht, geven we een opmerking over onze wijzigingen met behulp van de optie -m.

Als we onze werkmap willen bijwerken met een nieuwe versie van het project vanuit de repository, gebruiken we de update-opdracht, of in verkorte vorm omhoog:

   $ cvs update

CVS werd gebruikt door een groot aantal projecten, maar het was natuurlijk niet zonder gebreken dat later leidde tot het verschijnen van het volgende systeem in kwestie. Overweeg de belangrijkste nadelen:

• Omdat versies zijn opgeslagen in RCS-bestanden, is het niet mogelijk om directoryversies op te slaan. De standaardmanier om dit te omzeilen is door een bestand (bijvoorbeeld README.txt) op te slaan 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, de oude te verwijderen met de opdracht cvs remove en vervolgens met de nieuwe naam toe te voegen met de opdracht cvs add;

Subversie

Subversion (SVN) is in 2000 ontwikkeld op initiatief van CollabNet. SVN is oorspronkelijk ontwikkeld als de "beste CVS" en de belangrijkste taak van de ontwikkelaars was om fouten in het ontwerp van CVS te corrigeren met behoud van een vergelijkbare interface. SVN gebruikt, net als CVS, een client-serverarchitectuur. De belangrijkste wijzigingen ten opzichte van CVS zijn:

• Atomaire veranderingen (vastleggen). Als de verwerking van de commit werd onderbroken, zullen er geen wijzigingen worden aangebracht.
• Het hernoemen, kopiëren en verplaatsen van bestanden bewaart de hele geschiedenis van wijzigingen.
• Mappen, symbolische koppelingen en metagegevens zijn onderhevig aan versiebeheer.
• Efficiënte opslag voor binaire bestanden.

Overweeg de voorbeelden van commando's, hoewel moet worden opgemerkt dat de meeste van hen de CVS-commando's praktisch herhalen. Om een \u200b\u200bproject met SVN te gebruiken, moet je het eerst in de repository importeren met de importopdracht:

   $ cd een-project $ svn import -m "Nieuw project" pad-in-repository

In tegenstelling tot CVS hoeft u geen ontwikkelaars- en projecttags op te geven die in de praktijk niet vaak worden gebruikt.

Nu moeten we een werkkopie van het project maken met de checkout-opdracht, of co:

   $ cd some-working-dir $ svn checkout path-in-repository

Nadat we de wijzigingen hebben aangebracht, gebruiken we de opdracht commit (de wijzigingen vastleggen) of ci om de wijzigingen in de repository op te slaan:

   $ svn commit -m "Enkele wijzigingen"

En om de werkkopie van het project bij te werken, gebruikt u de update-opdracht of omhoog.

Ik vraag me af hoeveel elektronische ingenieurs geen versiebeheersystemen gebruiken in hun ontwerpen. Ik was zo tot ik het probeerde. Nu begin ik elk project met het maken van een repository.

Wat het is?

Waarom is dit nodig?

Zo ben ik onlangs begonnen met het verlagen van snelheidslimieten in een project op FPGA. In slechts 5 minuten vond ik een versie waarin ze nog niet waren gevallen en vond de reden

Als er meerdere mensen aan een project werken, is het praktisch onmogelijk om zonder SUV te werken - chaos begint, iedereen doet iets anders en het is niet duidelijk wie wat heeft gedaan. Met SUV kunt u gemakkelijk zien wie en wat heeft gedaan, wijzigingen die door anderen zijn aangebracht, worden veel minder onverwacht.

Daarnaast zijn er meer exotische toepassingen. Ik stuur bijvoorbeeld wijzigingen aan deze site door naar de server met behulp van het versiebeheersysteem.

Welke moet je kiezen?

Naast Mercurial zijn git en svn nu heel gewoon. Git komt vaker voor in de Linux-omgeving, svn in de bedrijfsomgeving. Ik heb geprobeerd ze te gebruiken (hoewel niet erg lang), maar ik zag niets dat de moeite waard was om met kwik te gooien.

Er is zo'n site, waarop u uw projecten kunt opslaan. Het is opmerkelijk dat je daar, in tegenstelling tot github, gratis gesloten opslagplaatsen kunt maken (de opslagplaats is de plaats waar projecten worden opgeslagen). U hoeft alleen te betalen voor die projecten die zijn afgesloten en waaraan meer dan 5 mensen werken. Tegelijkertijd kan de limiet worden uitgebreid tot 8 mijl door uitnodigingen te verzenden. Tot dusver heb ik deze limiet niet overschreden. Daarnaast is er een wiki- en bugtracker, in het algemeen alles wat je nodig hebt om projecten te ontwikkelen.

  Toen ik ermee begon te werken, ondersteunde de site alleen Mercurial (mede hierdoor koos ik voor mercurial), maar nu kun je daar ook git repositories aanmaken. Daarnaast kunt u uw domein aan bitbucket binden. Hier is bijvoorbeeld mijn optie: hg.bsvi.ru

Hoe te beginnen?

Gebruikersnaam \u003d bsvi

Uiteraard moet bsvi worden vervangen door uw naam.

Nu zijn we klaar om een \u200b\u200bproject te maken en iets te gaan doen. Klik hiertoe op "Opslagplaats maken":

We vullen de naam, beschrijving in, selecteren de taal. U kunt een wiki en een bugtracker toevoegen.

Klik nu op de kloonknop en kopieer wat daar verscheen:

Verdere bewerkingen zijn afhankelijk van welke bestandsbeheerder u gebruikt. Persoonlijk gebruik ik ver. Ik plak de gekopieerde regel gewoon in de opdrachtregel:

Als u een dirigent (um), totale commandant of iets dergelijks gebruikt, moet u met de rechtermuisknop klikken en selecteren:


  Daar, in het bronveld, moet je het pad natuurlijk invoegen zonder hg-kloon:

U wordt gevraagd naar uw wachtwoord en de test-repo-directory verschijnt waarin het project zich daadwerkelijk zal bevinden.

Voeg enkele bestanden toe

  #include   int main () (retourneer 0;)

Laten we nu vastleggen. Een commit is een wijziging in een project. Om dit te doen, voert u hg workbench uit. Ik schrijf gewoon thg op de opdrachtregel, voor verkennerachtige bestandsbeheerders moet je op RMB-\u003e Hg Workbench klikken.

Tegenover ons bestand staat een vraagteken (dit betekent dat het niet aan het project is toegevoegd). Zet er een vinkje naast en schrijf een beschrijving van wat er is gedaan:


  Klik daarna natuurlijk op de vastlegknop.

Alles, er zijn wijzigingen in het project aangebracht. Hier moet u erop letten dat de wijzigingen alleen op de lokale computer worden aangebracht (dat wil zeggen, ze staan \u200b\u200bnog niet op de server). Om de wijzigingen naar de server over te dragen, moet u op de drukknop klikken, hier is het:

Om de wijzigingen naar de server te pushen, is natuurlijk een wachtwoord vereist.

Wijzig het bestand

  #include   int main () (printf ("mercurial rules!"); return 0;)

Laten we verder gaan met hg workbench. Wanneer ik aan een project werk, sluit ik het niet eens (daarover later meer), druk op f5 om de lijst met bestanden bij te werken. Nu kun je zien wat er is veranderd sinds de laatste commit:

En dit is een zeer krachtig hulpmiddel. Meestal verschijnt er tijdens het debuggen veel verschillende rotzooi in de bestanden. Eend, kijkend naar wat je gaat plegen, reinigt het project heel goed van afval.

Wat te doen met afval?

Voeg het ongewenste bestand toe aan het project. Ik heb bijvoorbeeld main.obj gemaakt:

Als u de lijst met bestanden nu bijwerkt, biedt hg workbench natuurlijk aan om dit bestand aan het project toe te voegen:

Maak nu het .hgigonre-bestand en schrijf daar dat we alle bestanden met de obj-extensie willen negeren:
  syntaxis: glob * .obj

Als u de lijst met bestanden bijwerkt, verdwijnen obj-bestanden, maar verschijnt het .hgignore-bestand dat u kunt vastleggen:

Hoe de wijzigingen ongedaan maken?

Op precies dezelfde manier kunt u een afzonderlijk bestand terugdraaien.

Conclusie

Veel mensen denken dat versiebeheersystemen alleen mogen worden gebruikt als je iets met een grote menigte ontwikkelt, maar dit is niet zo :) Zelfs als je alleen aan een project werkt, helpen versiebeheersystemen veel.

Hier is bijvoorbeeld een screenshot van mijn UTC (die ik zelf aan het ontwikkelen ben) op de moeilijkste plek in hg workbench:

Heeft u een geweldig nieuw zakelijk idee met betrekking tot softwareontwikkeling?Wilt u een technologisch geavanceerde oplossing ontwikkelen? Of heb je een groot team van programmeurs die aan één taak werken? Onthoud dan deze drie woorden:versiecontrolesysteem .

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

,   of vcs- dit is iets dat zal voorkomen dat het project uit elkaar valt als er veel mensen aan werken. Programmeurs, managers, tekstschrijvers kunnen elk aan hun stuk werken, zonder elkaar te hinderen en zonder schade te veroorzaken die niet kon worden hersteld.

Als u niet bekend bent met het conceptversiebeheersystemendan   alles wordt heel duidelijk weergegeven.

Of bekijk een video van GitHub.

Dus welk versiebeheersysteem is geschikt voor uw project?

We hebben verschillende populaire oplossingen vergeleken om het voor u gemakkelijker te maken om een \u200b\u200bkeuze te maken.

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

Versiebeheersystemen, waaronder de bekende SVN (Subversion) en Git, zijn oorspronkelijk gemaakt zodat ontwikkelteams zonder verwarring aan gezamenlijke projecten kunnen werken. In het controlesysteem hoeft u niet zelfstandig codetakken te volgen en er aantekeningen bij te maken. In plaats daarvan wordt een centrale repository gebruikt, waar alles geordend, gestructureerd is. Het is handig om bestanden bij te werken, opmerkingen toe te voegen en zelfs projectvertakkingen samen te voegen.

Meningen over welkeversiecontrolesysteem  de beste verschillen sterk, en dit leidt tot een verhit debat onder programmeurs. Selecteren en studerenversiebeheersystemen  Vergeet voor uw project niet dat de voordelen van een oplossing vaak subjectief zijn. Bijvoorbeeld de persoonlijke voorkeuren van een programmeur of bijvoorbeeld indicatoren zoals snelheid, kenmerken van IDE-plug-ins, enz.

Het belangrijkste verschil tussen versiebeheersystemen is of ze client-server of gedecentraliseerd zijn (p2p). Hebben ze een centrale repository (server), waar komt de code vandaan en waar komt deze terug met de aangebrachte wijzigingen. Of is het een kopie in de lokale opslag, bijgewerkt door peers: een meer gedecentraliseerd netwerk dat wordt gebruikt voor synchronisatie, uitwisseling van patches (wijzigingensets) en om de huidige code te ondersteunen.

Het is ook de moeite waard om de snelheid, functionaliteit en drempel van binnenkomst / ontwikkeling van een bepaald te overwegencontrolesystemen. Overweeg de meest voorkomendeversiebeheersystemen  en de redenen waarom programmeurs bepaalde oplossingen verkiezen.

Simultaan versiesysteem (CVS)

CVS   verscheen in de jaren 80 en is nog steeds populair bij zowel commerciële productontwikkelaars als open-sourceontwikkelaars.

CVS   onder voorwaardenGNU open licentieovereenkomst en stelt u in staat om de juiste versie van het project van de server te halen - "uitchecken "(extractie) en dan terug naar de server, "inchecken "(retour),  zoals aangepast.

Aanvankelijk CVS   is gemaakt om versieconflicten te voorkomen. Alle deelnemers kregen alleen de laatste versie van de code. Dit was het eerste versiebeheersysteem. De gebruiker moest snel wijzigingen aanbrengen in de repository, terwijl anderen hem niet voor waren.

Nu CVS   heeft ondersteuning bij het werken aan projecten met code branches. Het blijkt verschillende productopties met verschillende kenmerken, die later kunnen worden gecombineerd.

CVS-servers   meestal draaien op unix maarCVS -klanten zijn beschikbaar in andere populaire besturingssystemen.CVS - "volwassen", beproefdversiecontrolesysteem. Het is nog steeds een open source-systeem, maar tegenwoordig worden nieuwe functies vrij zelden toegevoegd.

Tegelijkertijd is CVSNT de versie die opvalt in een apart projectCVS   voor Windows-servers - nu breidt het zijn functionaliteit actief uit.

Voordelen:

• Bewezen technologie die al decennia op de markt is.

Nadelen:

• Het hernoemen of verplaatsen van bestanden wordt niet weerspiegeld in de geschiedenis
• Beveiligingsrisico's verbonden aan symbolische bestandskoppelingen
• Geen ondersteuning voor atomaire operaties, wat kan leiden tot code-corruptie
• Bewerkingen met codetakken zijn duurcontrole systeem  niet bedoeld voor langlopende projecten met codetakken

Apache Subversion (SVN)

Svn   gemaakt als alternatiefCVS   om tekortkomingen te corrigerenCVS   en zorg tegelijkertijd voor een hoge compatibiliteit ermee.

Zoals CVS , SVN is een gratis systeemversiebeheer   open source. Het enige verschil is dat het wordt gedistribueerd onder de Apache-licentie en niet onderGNU Open licentieovereenkomst.

Om de database-integriteit te behouden, gebruikt SVN de zogenaamde atoombewerkingen. Als er een nieuwe versie verschijnt, worden alle correcties of geen enkele toegepast op het eindproduct. De code is dus beschermd tegen chaotische gedeeltelijke bewerkingen die niet consistent zijn met elkaar en fouten veroorzaken.

Veel ontwikkelaars zijn overgestapt opSVN als nieuwe technologie erft betere functiesCVS   en breidde ze tegelijkertijd uit.

In CVS   bewerkingen met codetakken zijn duur en worden niet geleverd door de systeemarchitectuur; SVN is speciaal hiervoor gemaakt. Dat wil zeggen voor grotere projecten met code-vertakking en veel ontwikkelgebieden.

De nadelen van SVN zijn de relatief lage snelheid en het gebrek aan gedistribueerde versiecontrole. Verdeeldversiebeheer   gebruikt een peer-to-peer-model in plaats van een gecentraliseerde server om code-updates op te slaan. Hoewel het peer-to-peer-model beter werkt in open source-projecten, is het in andere gevallen niet ideaal. Het nadeel van de serverbenadering is dat wanneer de server crasht, de clients geen toegang hebben tot de code.

Voordelen:

• Gebaseerd systeemCVS
• Maakt atomaire operaties mogelijk
• Code-vertakkingen zijn goedkoper
• Ruime keuze aan IDE-plug-ins
• Gebruikt geen peer-to-peer-model

Nadelen:

• Fouten blijven bestaan, gerelateerd aan het hernoemen van bestanden en mappen
• Een onbevredigende set opdrachten voor het werken met de repository
• Relatief lage snelheid

Git

Dit systeem is gemaakt om de ontwikkeling van de Linux-kernel te beheersen en gebruikt een aanpak die fundamenteel verschilt van CVS en SVN.

Basis Git   vastgelegde concepten ontworpen om een \u200b\u200bsnellere distributie te creërenversiecontrolesysteem, in tegenstelling tot de regels en beslissingen die inCVS . Aangezien Git voornamelijk onder Linux is ontwikkeld, werkt het in dit besturingssysteem het snelst.

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

Programmacode is mogelijk niet beschikbaar bij gebruik van een computer zonder een repository. Er zijn oplossingen om dit probleem op te lossen en sommige ontwikkelaars zijn van mening dat Git-prestaties een eerlijke vergoeding zijn voor het ongemak.

Daarnaast heeft Git veel tools om door de wijzigingsgeschiedenis te navigeren. Elke werkkopie van de broncode bevat de volledige ontwikkelingsgeschiedenis, wat erg handig is als je programmeert zonder internetverbinding.

Voordelen:

• Geweldig voor degenen die hatenCVS / SVN
• Significante prestatieverbetering
• Goedkope codetakoperaties
• Volledige ontwikkelingsgeschiedenis offline beschikbaar
• Gedistribueerd peer-to-peermodel

Nadelen:

• Hoge instapdrempel (training) voor degenen die eerder SVN hebben gebruikt
• Beperkte Windows-ondersteuning (vergeleken met Linux)

Mercurial

Mercurial   werd gelijktijdig met git uitgebracht. het is hetzelfde  verdeeld versiecontrolesysteem.

Mercurial is gemaakt als alternatief voor Git voor het ontwikkelen van Linux-kernelmodules. Maar omdat er toch voor Git is gekozen, wordt Mercurial minder gebruikt. Desalniettemin werken bijvoorbeeld veel vooraanstaande ontwikkelaars met dit systeemOpenoffice.org .

Het Mercurial-versiebeheersysteem verschilt van andereversiebeheersystemen  omdat het voornamelijk in Python is geschreven (en niet in C). Sommige onderdelen zijn echter ontworpen als uitbreidingsmodules in C.

Omdat het systeem gedecentraliseerd en in Python is geschreven, hebben veel Python-programmeurs de neiging om over te schakelen naar Mercurial.

Gebruikers merken op dat Mercurial enkele van de kenmerken van SVN behield, terwijl het een gedistribueerd systeem was, en vanwege deze gelijkenis is de instapdrempel lager voor degenen die al bekend zijn met SVN. Bovendien is de Mercurial-documentatie uitgebreider, waardoor u snel aan de verschillen kunt wennen.

Een van de grootste nadelen van Mercurial is dat het, in tegenstelling tot Git, niet mogelijk is om twee bovenliggende branches erin te combineren, aangezien Mercurial een plug-in-systeem gebruikt in plaats van scriptondersteuning. Dit is geweldig voor sommige programmeurs, maar velen willen Git niet opgeven.

Voordelen:

• Vergeleken met Git, makkelijker te leren
• Gedetailleerde documentatie
• Gedistribueerd modelversiebeheersystemen

Nadelen:

• Er is geen manier om twee bovenliggende takken samen te voegen
• Plug-ins gebruiken, geen scripts
• Minder mogelijkheden voor maatwerkoplossingen

Welkeversiebeheersysteem past bij mij?

In de meeste gevallen gebruiken ontwikkelaarsCVS   omdat het hen meer bekend is. Als het team al aan een project werkt, dan is het vooruitzicht om alle ontwikkelingen op een ander over te dragencontrole systeem  op de een of andere manier niet inspirerend. Als ze het systeem nog moesten wijzigen, zouden ze hoogstwaarschijnlijk overstappen op SVN.

CVS heeft de status van "volwassen technologie" al bereikt, wat betekent dat het niet langer radicaal nieuwe functies en oplossingen zal hebben. De traagheid van gewoonte gaat verloren als mensen overstappen op SVN. CVS behoort dus geleidelijk tot het verleden.

Tegenwoordig heeft SVN de leiding onder de serverversiebeheersystemen. Het omvat voordelen.CVS   en superieur aan hen. Als we het hebben over de prevalentie, is de kans groter dat u die tegenkomtCVS   of SVN dan met Git of Mercurial. Kennis van één servertechnologie zal, hoewel niet noodzakelijk, uw overgang vergemakkelijken.

Vanwege het wijdverbreide gebruik en de volwassenheid van de technologie heeft SVN een grote kennisbank, waardoor gebruikers gemakkelijk hulp kunnen krijgen.

Git is duidelijk sneller dan zijn concurrenten. Voor projecten die onder gedistribueerd zijn gemaaktversiebeheersystemenDit is een duidelijke verbetering.

Een belangrijk nadeel van Git is dat het soms moeilijk is om de nuances hiervan te verklarencontrolesystemen, en het vertraagt \u200b\u200bde workflow terwijl programmeurs eraan wennen. Maar zodra de "instapdrempel" wordt overschreden, neemt de productiviteit toe en compenseert het gemak van het beheren van codetakken de bestede tijd volledig.

Voor degenen die Git niet kunnen uitstaan \u200b\u200b(en dit systeem heeft zijn tegenstanders in de ontwikkelomgeving), Mercurial is een compromis tussen SVN en Git. Dit systeem wordt gebruikt in veel bekende projecten en heeft ook een goede documentatie.

De Windows-compatibele versie van Git vordert ook en nadert de Linux-versie in snelheid, dus dit systeem kan relevant voor je zijn, zelfs als je niet op Linux ontwikkelt.

Om te begrijpen wat voor u het beste is, moet u rekening houden met de kenmerken van het project en uw team. Praat met de ontwikkelaars!

Als een project een enkele source tree nodig heeft waaraan een kleine groep programmeurs zal werken, dan is SVN jouw optie. Het is betrouwbaar en speciaal ontworpen voor dergelijke gevallen.

Als je een open-sourceproject lanceert waaraan verschillende programmeurs op verschillende tijden zullen werken, of als je van plan bent de code constant bij te werken, selecteer dan Git. De snelheid en controle van de source tree is hier veel beter dan in SVN.

Als je op een kruispunt staat of je houdt gewoon niet van hoe SVN of Git werkt, dan staat Mercurial voor je klaar.

Al deze systemen zijn volledig functioneel. En ook gratis. Ze worden gebruikt om software, sites en zelfs besturingssystemen te maken die u gebruikt en die u kent.

Bepaal allereerst of dit of datcontrole systeem  versies voor uw bedrijf, en zorg er - net zo belangrijk - voor dat programmeurs niet woedend worden.

Aan de slag met SVN

Als je nog nooit met SVN of Git hebt gewerkt en geen idee hebt hoe je moet beginnen, danhosting oplossing gecombineerd met een grafische interface  helpen u snel comfortabel te worden.

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

NOTITIE:  Daar zijn veel hostingoplossingen voorversiebeheersystemen, ook met een gratis proefperiode. U kunt uw eerste repository (een plaats voor samenwerking met codebestanden) volledig gratis maken. Hier zijn enkele van deze services:

Hosting SVN & GIT

Het creëren van de eerste repository

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

• Log in op uw account, klik op uw projecten.
• Project Creatie:

• Voer in de regel "Maak een nieuw project" de naam van uw project in
• Klik op de knop Project maken

• SVN-verbinding:

• Selecteer na het aanmaken van het project het tabblad "Source Control" (broncodeversies)
• Klik op de link "Enable Source Control"
• Geef de repository een naam
• Klik op "Opslaan"

Grafische klanten van SVN en GIT

Dus de repository is gemaakt. Nu is het nodig dat alles er eenvoudig en duidelijk in staat. Hiervoor heeft u een grafische interface nodig.

—  handig programma om mee te werkenversiebeheersystemen  op Microsoft Windows en mogelijk de beste Apache Subversion-client die ooit is geïntroduceerd. TortoiseSVN is geïmplementeerd als een uitbreiding op de Windows-shell, waardoor het gemakkelijk te integreren is inbrowser.   Het is ook een open source programma waarvoor 34 taalpakketten beschikbaar zijn.

Smartgit

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

  "Uitpakken" van de repository ("Uitchecken")

Dus de klant is geselecteerd. Nu moet je een opslagplaats maken voor het besturingssysteem. Moet binnenkomenDe URL van uw repository, gebruikersnaam en wachtwoord.

De URL ziet er meestal als volgt uit:https: // svn .hostnaam.com / svn / > (u kunt https: // (SSL) gebruiken als u een betaald account heeft)

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

Nadat u de bestanden heeft gewijzigd om ze op te slaan, klikt u op de knop "Inchecken" op de werkbalk. U kunt de wijzigingen bekijken en er opmerkingen aan toevoegen - dit is een redelijk goed idee, omdat u in de toekomst precies weet waar u aan hebt gewerkt, welke wijzigingen zijn aangebracht en u op de hoogte houdt van andere projectdeelnemers.

Uw cliënt zou ook de mogelijkheid moeten hebben om op elk moment met revisies te gaan werken door het revisielogboek of de wijzigingsgeschiedenis te openen. Vervolgens kunt u indien nodig voor elk bestand afzonderlijk teruggaan naar de vorige versie. Nu u bekend bent met de basisconcepten, de documentatie

Overzicht van het versiebeheersysteem

Versiebeheersystemen zijn niet alleen een integraal onderdeel van het leven geworden voor softwareontwikkelaars, maar ook voor alle mensen die worden geconfronteerd met het probleem van het beheren van snel veranderende informatie en die hun leven gemakkelijker willen maken. Als gevolg hiervan zijn er een groot aantal verschillende producten verschenen, die geweldige functies bieden en uitgebreide versiecontroletools bieden. In dit artikel worden de meest populaire van hen kort besproken, hun voor- en nadelen worden gegeven.

Ter vergelijking zijn de meest voorkomende versiebeheersystemen geselecteerd: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

  RCS - Version Revision Management System.
(www.gnu.org/software/rcs/rcs.html)

We beginnen onze beoordeling met een van de eerste versiecontrolesystemen - RCS (Revision Control System - revision control system), ontwikkeld in 1985. Het verving het populaire versiebeheersysteem SCCS (Source Code Control System - source code control system).

Op dit moment wordt RCS actief vervangen door een krachtiger CVS-versiebeheersysteem, maar nog steeds behoorlijk populair, en maakt deel uit van het GNU-project.

Met RCS kunt u alleen met afzonderlijke bestanden werken, waardoor voor elk een wijzigingsgeschiedenis wordt aangemaakt. Voor tekstbestanden worden niet alle versies van het bestand opgeslagen, maar alleen de nieuwste versie en alle daarin aangebrachte wijzigingen. RCS kan ook wijzigingen in binaire bestanden volgen, maar elke wijziging wordt opgeslagen als een afzonderlijke versie van het bestand.

Wanneer een van de gebruikers wijzigingen aanbrengt in het bestand, blijft dit bestand voor alle anderen vergrendeld. Ze kunnen het pas bij de repository opvragen voor bewerking als de eerste gebruiker klaar is met werken en de wijzigingen doorvoert.

Laten we eens kijken naar de belangrijkste voor- en nadelen van het RCS-versiebeheersysteem.

Voordelen:

1. RCS - gemakkelijk te gebruiken en goed geschikt om vertrouwd te raken met de principes van versiebeheersystemen.

2. Zeer geschikt voor het maken van back-ups van individuele bestanden die niet vaak door een groep gebruikers hoeven te worden gewijzigd.

3. Wijd verspreid en vooraf geïnstalleerd op de meeste vrij verspreide besturingssystemen.

Nadelen:

1. Traceert wijzigingen alleen in individuele bestanden, wat het niet toestaat het te gebruiken voor versiebeheer van grote projecten.

2. Staat niet toe dat meerdere gebruikers gelijktijdig wijzigingen aanbrengen in hetzelfde bestand.

3. Lage functionaliteit in vergelijking met moderne versiebeheersystemen.

Bevindingen:

RCS-versiebeheersysteem biedt een te zwakke set tools voor het beheren van ontwikkelde projecten en is alleen geschikt voor kennismaking met versiebeheertechnologie of voor het bijhouden van een kleine geschiedenis van het terugdraaien van individuele bestanden.

  CVS is een parallel versiebeheersysteem.
(www.nongnu.org/cvs)

Het Concurrent Versions-systeem is een logische ontwikkeling van het versiebeheersysteem (RCS), dat gebruik maakt van de standaarden en algoritmen voor versiebeheer, maar veel functioneler is, waardoor u niet alleen met afzonderlijke bestanden kunt werken, maar ook met hele projecten.

CVS is gebaseerd op client-servertechnologie die via het netwerk interageert. De client en server kunnen zich ook op dezelfde machine bevinden als er maar één persoon aan het project werkt of als lokaal versiebeheer vereist is.

Het CVS-werk is als volgt georganiseerd. De nieuwste versie en alle aangebrachte wijzigingen worden opgeslagen in de serverrepository. Clients die verbinding maken met de server controleren de verschillen tussen de lokale versie en de nieuwste versie die is opgeslagen in de repository en, als er verschillen zijn, uploaden ze naar hun lokale project. Los zo nodig conflicten op en breng de gewenste wijzigingen aan in het ontwikkelde product. Daarna worden alle wijzigingen gedownload naar de serverrepository. Met CVS kunt u indien nodig teruggaan naar de gewenste versie van het ontwikkelde project en meerdere projecten tegelijkertijd beheren.

Hier zijn de belangrijkste voor- en nadelen van het parallelle versiebeheersysteem.

Voordelen:

1. Meerdere klanten kunnen tegelijkertijd aan hetzelfde project werken.

2. Hiermee kunt u niet slechts één bestand beheren, maar volledige projecten.

3. Het heeft een groot aantal handige grafische interfaces die aan bijna elke, zelfs de meest veeleisende, smaak kunnen voldoen.

4. Wijdverbreid en wordt standaard geleverd bij de meeste Linux-besturingssystemen.

5. Bij het laden van testbestanden vanuit de repository worden alleen wijzigingen overgedragen en niet het hele bestand.

Nadelen:

1. Wanneer u een bestand of map verplaatst of hernoemt, gaan alle wijzigingen die aan dit bestand of deze map zijn gekoppeld, verloren.

2. Moeilijkheden om meerdere parallelle takken van hetzelfde project te onderhouden.

3. Beperkte ondersteuning voor lettertypen.

4. Voor elke wijziging in het binaire bestand wordt de volledige versie van het bestand opgeslagen, niet alleen de aangebrachte wijziging.

5. Van de client naar de server wordt het gewijzigde bestand altijd volledig overgedragen.

6. Hulpbronnenintensieve bewerkingen, aangezien ze veelvuldige toegang tot de repository vereisen, en opgeslagen kopieën hebben enige redundantie.

Bevindingen:

Ondanks het feit dat CVS verouderd is en ernstige tekortkomingen heeft, is het nog steeds een van de meest populaire versiebeheersystemen en is het geweldig voor het beheren van kleine projecten waarvoor niet de creatie van meerdere parallelle versies nodig is die periodiek moeten worden gecombineerd. CVS kan worden aanbevolen als tussenstap in de ontwikkeling van versiebeheersystemen, wat leidt tot krachtigere en modernere soorten van dergelijke programma's.

  Subversion versiebeheersysteem.
(www.subversion.tigris.org)

Subversion is een gecentraliseerd versiebeheersysteem dat in 2000 is gemaakt en is gebaseerd op client-servertechnologie. Het heeft alle voordelen van CVS en lost de belangrijkste problemen op (hernoemen en verplaatsen van bestanden en mappen, werken met binaire bestanden, enz.). Vaak wordt het genoemd met de naam van het clientgedeelte - SVN.

Het principe van werken met Subversion lijkt erg op het werken met CVS. Klanten kopiëren de wijzigingen uit de repository en combineren ze met het lokale project van de gebruiker. Als er conflicten ontstaan \u200b\u200btussen lokale wijzigingen en wijzigingen die zijn opgeslagen in de repository, worden dergelijke situaties handmatig opgelost. Vervolgens worden er wijzigingen aangebracht in het lokale project en wordt het resultaat opgeslagen in de repository.

Bij het werken met bestanden die het samenvoegen van wijzigingen niet toestaan, kan het volgende principe worden gebruikt:

1. Het bestand wordt gedownload uit de repository en geblokkeerd (downloaden vanuit de repository is verboden).

2. De nodige wijzigingen worden aangebracht.

3. Het bestand wordt geüpload naar de repository en ontgrendeld (andere clients mogen het downloaden vanuit de repository).

Grotendeels vanwege de prostaat en de overeenkomsten in het beheer van CVS, maar vooral vanwege de brede functionaliteit, concurreert Subversion met succes met CVS en vervangt het zelfs met succes.

Subversion heeft echter zijn nadelen. Laten we eens kijken naar de sterke en zwakke punten voor vergelijking met andere versiebeheersystemen.

Voordelen:

1. Commandosysteem vergelijkbaar met CVS.

2. De meeste CVS-functies worden ondersteund.

3. Een verscheidenheid aan grafische interfaces en gemakkelijke bediening vanaf de console.

4. De geschiedenis van wijzigingen in bestanden en mappen wordt bijgehouden, zelfs nadat ze zijn hernoemd en verplaatst.

5. Hoge efficiëntie, zowel met tekst als binaire bestanden.

6. Native ondersteuning in veel geïntegreerde ontwikkeltools, zoals KDevelop, Zend Studio en vele andere.

7. Mogelijkheid om spiegelkopieën van de repository te maken.

8. Twee soorten opslagplaatsen: een database of een set gewone bestanden.

9. Mogelijkheid om toegang te krijgen tot de repository via Apache met behulp van het WebDAV-protocol.

10. De aanwezigheid van een handig mechanisme voor het maken van labels en projecttakken.

11. U kunt aan elk bestand en elke map een specifieke set eigenschappen koppelen die interactie met het versiebeheersysteem vergemakkelijken.

12. Door de wijdverspreide distributie kunt u snel de meeste problemen oplossen die zich voordoen, verwijzend naar de gegevens die door de internetgemeenschap zijn verzameld.

Nadelen:

1. Een volledige kopie van de repository wordt op de lokale computer opgeslagen in verborgen bestanden, wat een vrij grote hoeveelheid geheugen vereist.

2. Er zijn problemen met het hernoemen van bestanden als een lokaal hernoemd bestand door een client tegelijkertijd door een andere client is gewijzigd en naar de repository is geüpload.

3. Steun zwakke samenvoeging van projectafdelingen.

4. Moeilijkheden met het volledig verwijderen van informatie over bestanden die in de repository zijn gekomen, omdat het altijd informatie bevat over eerdere wijzigingen in het bestand, en er zijn geen reguliere middelen voorzien om gegevens over het bestand volledig uit de repository te verwijderen.

Bevindingen:

Subversion is een modern versiebeheersysteem met een breed scala aan tools om te voldoen aan alle behoeften voor projectversiecontrole met behulp van een gecentraliseerd besturingssysteem. Veel bronnen op internet zijn gewijd aan de functies van Subversion, waarmee u snel en nauwkeurig alle problemen die zich tijdens het werk voordoen, kunt oplossen.

De eenvoud van installatie, voorbereiding op werk en brede mogelijkheden maken het mogelijk om subversie op een van de leidende posities in de competitieve race van versiebeheersystemen te plaatsen.

  Aegis-versiebeheersysteem.

Aegis, in 1991 door Peter Miller gecreëerd, is het eerste alternatief voor gecentraliseerde versiebeheersystemen. Alle bewerkingen daarin worden uitgevoerd via het Unix-bestandssysteem. Helaas heeft Aegis geen ingebouwde netwerkondersteuning, maar u kunt communiceren met protocollen zoals NFS, HTTP, FTP.

Het belangrijkste kenmerk van Aegis is een manier om wijzigingen in de repository te beheren.

Voordat ze wijzigingen aanbrengen, moeten ze eerst een reeks tests doorstaan. En als innovaties in de broncode van het programma de tests niet doorstaan, moet u nieuwe tests toevoegen of mogelijke fouten in de broncode corrigeren.

Ten tweede moeten ze, voordat ze wijzigingen aanbrengen in de hoofdtak van een ontwikkeld project, door de browser worden goedgekeurd.

Ten derde wordt een hiërarchie van toegang tot de repository geboden, gebaseerd op een systeem van toegangsrechten voor Unix-achtige besturingssystemen tot bestanden.

Dit alles maakt het gebruik van het Aegis-versiebeheersysteem betrouwbaar, maar uiterst gecompliceerd en zelfs goed ontwikkelde documentatie maakt het niet veel eenvoudiger.

We benadrukken de belangrijkste voor- en nadelen van het Aegis-versiebeheersysteem.

Voordelen:

1. Betrouwbare controle over de juistheid van gedownloade wijzigingen.

2. De mogelijkheid om verschillende toegangsniveaus te bieden tot de repositorybestanden, wat een behoorlijk beveiligingsniveau biedt.

3. Kwaliteitsdocumentatie.

4. De mogelijkheid om bestanden die in de repository zijn opgeslagen te hernoemen, zonder de geschiedenis van wijzigingen te verliezen.

5. Mogelijkheid om met een lokale repository te werken als er geen netwerktoegang tot de hoofdrepository is.

Nadelen:

1. Gebrek aan ingebouwde ondersteuning voor netwerken.

2. De complexiteit van het opzetten en werken met de repository.

3. Zwakke grafische interfaces.

Bevindingen:

De complexiteit van Aegis kan gebruikers vervreemden van het gebruik van versiebeheersystemen, dus het kan niet worden aanbevolen voor beoordeling of voor kleine softwareprojecten. Het heeft echter een aantal voordelen die in sommige specifieke situaties nuttig kunnen zijn, vooral wanneer een strikte kwaliteitscontrole van de te ontwikkelen software vereist is.

  Monotoon versiecontrolesysteem.
(monotoon.ca)

Monotoon is een ander gedecentraliseerd versiebeheersysteem dat is ontwikkeld door Gradon Hoam. Daarin is elke klant verantwoordelijk voor het synchroniseren van versies van het ontwikkelde product met andere klanten.

Werken met dit versiebeheersysteem is vrij eenvoudig en veel opdrachten lijken op de opdrachten die worden gebruikt in Subversion en CVS. De verschillen liggen vooral in de organisatie van de fusie van projecttakken van verschillende ontwikkelaars.

Werken met Monotoon is als volgt opgebouwd. Allereerst wordt de SQLite-projectdatabase gemaakt en worden sleutels gegenereerd met behulp van het SHA1 (Secure Hash Algorithm 1) hash-algoritme.

Als de gebruiker het project vervolgens aanpast, worden alle wijzigingen in deze database opgeslagen, vergelijkbaar met het opslaan van wijzigingen in de repository van andere versiebeheersystemen.

Om het project met andere gebruikers te synchroniseren, moet u:

Exporteer de sleutel (hash-code van de nieuwste versie van het project) en ontvang vergelijkbare sleutels van andere klanten.

Nu kan elke op deze manier geregistreerde gebruiker de ontwikkeling synchroniseren met zijn collega's met behulp van een eenvoudige set opdrachten.

Vat de voor- en nadelen van het Monotone versiebeheersysteem samen.

Voordelen:

1. Een eenvoudige en begrijpelijke set commando's, vergelijkbaar met de Subversion- en CVS-commando's.

2. Ondersteunt het hernoemen en verplaatsen van bestanden en mappen.

3. Hoogwaardige documentatie, die het gebruik van versiebeheersystemen aanzienlijk vergemakkelijkt.

Nadelen:

1. Lage snelheid.

2. Het ontbreken van krachtige grafische schalen.

3. Mogelijke (maar extreem lage) hashcode-overeenkomsten van verschillende revisies in inhoud.

Bevindingen:

Monotoon is een krachtig en handig hulpmiddel voor versiebeheer van een ontwikkeld project. De set commando's is doordacht en intuïtief, vooral handig voor gebruikers die gewend zijn om met Subversion en CVS te werken. Met goed ontworpen en volledige documentatie kunt u snel wennen en alle functies van Subversion op volle capaciteit gebruiken.

De relatief lage snelheid en het gebrek aan krachtige grafische schalen kunnen het werken met grote projecten echter enigszins moeilijk maken. Daarom, als je een versiebeheersysteem nodig hebt om complexe en omvangrijke producten te ondersteunen, moet je aandacht besteden aan Git of Mercurial.

  Git versiebeheersysteem.
(www.git-scm.com)

Sinds februari 2002 gebruiken de meeste programmeurs het BitKeeper-versiebeheersysteem om de Linux-kernel te ontwikkelen. Lange tijd waren er geen problemen mee, maar in 2005 trok Larry McVoy (de ontwikkelaar van BitKeeper) de gratis versie van het programma in.

Het is onmogelijk om een \u200b\u200bLinux-schaal project te ontwikkelen zonder een krachtig en betrouwbaar versiebeheersysteem. Een van de kandidaten en het meest geschikte project was het Monotine versiecontrolesysteem, maar Torvalds Linus was niet tevreden over de snelheid. Omdat de kenmerken van de Monatone-organisatie de snelheid van de gegevensverwerking niet significant verhoogden, begon Linus op 3 april 2005 met het ontwikkelen van zijn eigen versiebeheersysteem - Git.

Bijna gelijktijdig met Linus (drie dagen later) begon Matt Macal ook met de ontwikkeling van een nieuw versiebeheersysteem. Matt noemde zijn project Mercurial, maar daarover later meer, en nu terug naar het gedistribueerde versiebeheersysteem Git.

Git is een flexibel, gedistribueerd (zonder een enkele server) versiebeheersysteem dat niet alleen veel mogelijkheden biedt aan ontwikkelaars van softwareproducten, maar ook aan schrijvers om veranderingen in "manuscripten" en verhaallijnen te veranderen, aan te vullen en te volgen, en aan leraren om de cursus aan te passen en te ontwikkelen, en beheerders voor documentatie, en voor vele andere gebieden die het beheer van de wijzigingsgeschiedenis vereisen.

Elke ontwikkelaar die Git gebruikt, heeft zijn eigen lokale repository, die lokale versiecontrole mogelijk maakt. Vervolgens kunnen de gegevens die zijn opgeslagen in de lokale repository worden uitgewisseld met andere gebruikers.

Wanneer ze met Git werken, creëren ze vaak een centrale repository waarmee andere ontwikkelaars synchroniseren. Een voorbeeld van het organiseren van een systeem met een centrale opslagplaats is het Linux'-kernelontwikkelingsproject (http://www.kernel.org).

In dit geval voeren alle projectdeelnemers hun lokale ontwikkeling uit en downloaden ze gratis updates vanuit de centrale repository. Wanneer het noodzakelijke werk van individuele projectdeelnemers is voltooid en debuggen, uploaden zij, nadat de eigenaar van de centrale repository de juistheid en relevantie van het uitgevoerde werk heeft bevestigd, hun wijzigingen naar de centrale repository.

De aanwezigheid van lokale repositories verhoogt ook aanzienlijk de betrouwbaarheid van gegevensopslag, omdat als een van de repositories faalt, gegevens gemakkelijk kunnen worden hersteld vanuit andere repositories.

Werk aan versies van het project in Git kan worden uitgevoerd in verschillende branches, die vervolgens eenvoudig geheel of gedeeltelijk kunnen worden gecombineerd, vernietigd, teruggedraaid en uitgroeien tot steeds meer nieuwe branches van het project.

Het is mogelijk om de functies van Git lange tijd te bespreken, maar voor beknoptheid en gemakkelijker begrip geven we de belangrijkste voor- en nadelen van dit versiebeheersysteem

Voordelen:

1. Een betrouwbaar systeem voor het vergelijken van revisies en gegevensvalidatie op basis van het SHA1-hash-algoritme (Secure Hash Algorithm 1).

2. Een flexibel systeem van brancheprojecten en het samenvoegen van branches onderling.

3. De aanwezigheid van een lokale repository met volledige informatie over alle wijzigingen maakt volledige lokale controle van versies mogelijk en uploadt naar de hoofdrepository alleen volledig geteste wijzigingen.

4. Hoge prestaties en snelheid.

5. Handige en intuïtieve set opdrachten.

6. Veel grafische shells waarmee je snel en efficiënt met Git's kunt werken.

7. De mogelijkheid om controlepunten te maken waarop gegevens worden opgeslagen zonder delta-compressie, maar volledig. Hiermee kunt u de snelheid van gegevensherstel verlagen, aangezien het dichtstbijzijnde controlepunt als basis wordt genomen en het herstel daaruit voortkomt. Als er geen mijlpalen waren, zou het herstel van grote projecten uren kunnen duren.

8. Wijdverbreide, gemakkelijke toegankelijkheid en kwaliteitsdocumentatie.

9. Door de flexibiliteit van het systeem kunt u het gemakkelijk configureren en zelfs gespecialiseerde systeemcontroles of op git gebaseerde gebruikersinterfaces maken.

10. Universele netwerktoegang via de protocollen http, ftp, rsync, ssh, etc.

Nadelen:

1. Unix - oriëntatie. Er is momenteel geen volwassen Git-implementatie die compatibel is met andere besturingssystemen.

2. Mogelijke (maar extreem lage) hashcode-overeenkomsten van revisies met een verschillende inhoud.

3. De wijziging van individuele bestanden wordt niet gecontroleerd, maar alleen van het hele project als geheel, wat lastig kan zijn bij het werken met grote projecten die veel onsamenhangende bestanden bevatten.

4. Tijdens de eerste (eerste) creatie van de repository en synchronisatie met andere ontwikkelaars, zal het voldoende lang duren om de data te downloaden, vooral als het project groot is, omdat het nodig is om de volledige repository naar de lokale computer te kopiëren.

Bevindingen:

Git is een flexibel, handig en krachtig versiebeheersysteem dat de overgrote meerderheid van gebruikers tevreden kan stellen. Bestaande tekortkomingen worden geleidelijk aan weggenomen en brengen gebruikers niet in ernstige problemen. Als u een groot project uitvoert dat geografisch afgelegen is, en nog meer als u vaak software moet ontwikkelen zonder toegang tot andere ontwikkelaars (u wilt bijvoorbeeld geen tijd verliezen door van land naar land te vliegen of tijdens een reis naar uw werk), kunt u dat doen eventuele wijzigingen en sla ze op in de lokale repository, ga terug, wissel tussen branches, enz.). Git is een van de leiders in versiebeheersystemen.

  Mercurial versiecontrolesysteem.
(mercurial.selenic.com)

Het gedistribueerde versiebeheersysteem van Mercurial is ontwikkeld door Matt Macal, parallel aan het Git-versiebeheersysteem van Torvalds Linus.

Aanvankelijk was het gemaakt om grote projecten onder Linux's effectief te beheren, en was het daarom gericht op snel en betrouwbaar werken met grote repositories. Mercurial is momenteel aangepast voor Windows, Mac OS X en de meeste Unix-systemen.

Het grootste deel van het versiebeheersysteem is geschreven in Python en alleen bepaalde delen van het programma die de hoogste prestaties vereisen, zijn geschreven in C.

De revisies worden geïdentificeerd op basis van het SHA1 (Secure Hash Algorithm 1) hash-algoritme, maar het is ook mogelijk om revisies individuele nummers toe te wijzen.

Evenals in git’e wordt de mogelijkheid ondersteund om projectvertakkingen te maken met hun latere samenvoeging.

Voor communicatie tussen clients worden HTTP-, HTTPS- of SSH-protocollen gebruikt.

De set commando's is eenvoudig en intuïtief, in veel opzichten vergelijkbaar met subversion-commando's. Er is ook een aantal grafische skins en toegang tot de repository via de webinterface. Even belangrijk is de beschikbaarheid van hulpprogramma's waarmee u opslagplaatsen van veel andere versiebeheersystemen kunt importeren.

Overweeg de belangrijkste voor- en nadelen van Mercurial.

Voordelen:

1. Snelle gegevensverwerking.

2. Platformonafhankelijke ondersteuning.

3. Mogelijkheid om met verschillende takken van het project te werken.

4. Gemakkelijk te hanteren.

5. De mogelijkheid om opslagplaatsen van andere ondersteuningssystemen voor versies te converteren, zoals CVS, Subversion, Git, Darcs, GNU Arch, Bazaar, enz.

Nadelen:

1. Mogelijke (maar extreem lage) hashcode-overeenkomsten van revisies met een verschillende inhoud.

2. Het is gericht op werk in de console.

Bevindingen:

Een eenvoudige en geavanceerde interface en een reeks commando's, de mogelijkheid om opslagplaatsen te importeren van andere versiebeheersystemen, maken de overgang naar Mercurial en het trainen van de belangrijkste functies pijnloos en snel. Het is onwaarschijnlijk dat dit meer dan een paar dagen zal duren.

Met betrouwbaarheid en snelheid kunt u het gebruiken om versies van grote projecten te beheren. Dit alles maakt mercurial een waardige concurrent van git.

  Bazaar versiebeheersysteem.
(bazaar.canonical.com)

Bazaar is een gedistribueerd, vrij verspreid versiebeheersysteem dat is ontwikkeld met ondersteuning van Canonical Ltd. Het is geschreven in Python en draait op Linux, Mac OS X en Windows-besturingssystemen.

In tegenstelling tot Git en Mercurial, gemaakt om de kernelversies van het Linux-besturingssysteem te besturen, en daarom gericht op maximale prestaties bij het werken met een groot aantal bestanden, richtte Bazaar zich op een handige en vriendelijke gebruikersinterface. Optimalisatie van de werksnelheid werd al in de tweede fase uitgevoerd, toen de eerste versies van het programma al verschenen.

Zoals bij veel andere versiebeheersystemen, lijkt het Bazaar'a-commandosysteem sterk op de CVS- of Subversion-commando's, wat echter niet verrassend is, omdat het een handige, eenvoudige en intuïtieve interface biedt voor interactie met het programma.

Het is fijn dat er veel aandacht wordt besteed aan het werken met projecttakken (creëren, samenvoegen van takken, etc.), wat erg belangrijk is bij het ontwikkelen van serieuze projecten en je in staat stelt verbeteringen en experimenten uit te voeren zonder de dreiging de hoofdversie van de software te verliezen.

Een groot pluspunt van dit versiebeheersysteem is de mogelijkheid om te werken met repositories van andere versiebeheersystemen, zoals Subversion of Git.

We schetsen kort de belangrijkste voor- en nadelen van dit versiebeheersysteem.

Voordelen:

1. Platformonafhankelijke ondersteuning.

2. Handige en intuïtieve interface.

3. Eenvoudig werken met projecttakken.

4. Mogelijkheid om te werken met repositories van andere versiebeheersystemen.

5. Geweldige documentatie.

6. Handige grafische interface.

7. Extreme flexibiliteit om aan te passen aan de behoeften van een bepaalde gebruiker.

Nadelen:

1. Lagere snelheid vergeleken met git en mercurial, maar deze situatie wordt geleidelijk opgelost.

2. Voor een volledige werking is het noodzakelijk om een \u200b\u200bvoldoende groot aantal plug-ins te installeren waarmee u alle functies van het versiebeheersysteem volledig kunt onthullen.

Bevindingen:

Bazaar is een handig versiebeheersysteem met een mooie interface. Zeer geschikt voor gebruikers die worden afgestoten door de mogelijkheid om met de opdrachtregel te werken. Met veel extra opties en extensies kunt u het programma aanpassen aan uw behoeften. De gelijkenis van het commandosysteem met Git en Subversion, en de mogelijkheid om rechtstreeks met hun repositories te werken, zal de overgang naar Bazaar snel en pijnloos maken. Het succes van de bazaar blijkt ook uit het feit dat Ubuntu Linux-ontwikkelaars het gebruiken.

  Versiebeheersysteem Arch.

Arch is een gedistribueerd versiebeheersysteem gemaakt door Tom Lord. Aanvankelijk was het gemaakt om CVS-problemen op te lossen, wat ze redelijk goed deden.

Arch voert atomaire bewerkingen uit om wijzigingen in de repository op te slaan, d.w.z. sluit de situatie van het downloaden van de repository uit, wanneer sommige van de wijzigingen zijn gedownload en sommige nog niet zijn geladen.

Het ondersteunt de mogelijkheid om versies van het project te vertakken en individuele vertakkingen te combineren, bestanden en mappen te hernoemen en te verplaatsen met een geschiedenis van veranderingen en vele andere leuke functies.

Het vereist geen speciale service voor een netwerkrepository en kan protocollen gebruiken zoals FTP, SFTP of WebDAV enzovoort.

Maar helaas wordt het alleen ondersteund door UNIX-systemen, maar het overbrengen van Arch naar andere besturingssystemen zou niet moeilijk moeten zijn.

Het is moeilijk om fundamenteel betere eigenschappen op te merken in vergelijking met andere gedistribueerde versiebeheersystemen, zoals git, mercurial, bazaar, dus als je een keuze hebt, is het beter om iets krachtigers en wijdverspreiders te gebruiken.

  Perforce-versiebeheersysteem.
(www.perforce.com)

We blijven versiebeheersystemen herzien en gaan over op commerciële programma's. Laten we beginnen met een gecentraliseerd versiebeheersysteem - Perforce, ontwikkeld door Perforce Software.

Het Perforce-systeem heeft een client-serverorganisatie en stelt u in staat om tegelijkertijd meerdere projecten te beheren, waardoor voor elk project een opslagplaats wordt gecreëerd.

Perforce is een platformonafhankelijk systeem. Er zijn versies die kunnen draaien onder de besturingssystemen Unix, Mac OS X, Microsoft Windows.

Om met het versiebeheersysteem te werken, kunt u de console of een speciaal ontworpen grafische interface gebruiken.

Het grote voordeel van Perforce is de mogelijkheid om te integreren met vele software-ontwikkelingstools en applicaties zoals Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs en vele anderen.

Ondersteuning voor de mogelijkheid om takken van projectversies te creëren, ze flexibel te beheren, samen te voegen, terug te draaien naar eerdere revisies - maakt Perforce een volledig concurrerend systeem en draagt \u200b\u200bbij aan de brede distributie ervan. Dit product is echter commercieel, wat de reikwijdte enigszins beperkt en de distributie remt. Het wordt voornamelijk gebruikt in grote commerciële bedrijven waarvoor niet alleen functionaliteit belangrijk is, maar ook tijdige technische ondersteuning.

  Versiebeheersysteem van Team Foundation Server.
(msdn.microsoft.com/en-us/library/ms364061.aspx)

In feite kun je Team Foundation Server (TFC) niet zomaar een versiebeheersysteem noemen - het is een soort complexe oplossing met een versiebeheersysteem, een gegevensverzamelsysteem, het genereren van rapporten en andere nuttige functies.

Een beheerd project bij het werken met TFC bestaat uit vertakkingen van de broncode van het project, sets rapporten en gebruikerselementen. Bij het maken van een project worden de parameters vooraf geselecteerd, die onafhankelijk kunnen worden geselecteerd of sjablonen kunnen worden gebruikt. Met de sjablonen kunt u het ontwikkelingstraject van het project bepalen, het flexibel of star geformaliseerd maken, een ontwikkelingsstrategie opstellen en rekening houden met de nodige conceptdocumenten en rapporten.

TFC kan eenvoudig worden geïntegreerd met Microsoft Excel en Microsoft Project, wat het maken en volgen van elementen van gecontroleerde projecten aanzienlijk vergemakkelijkt.

Als versiebeheersysteem kunt u met TFC:

Projectbestanden gezamenlijk aanpassen;

Conflicten oplossen;

Maak projectbranches en voeg ze vervolgens samen;

Beheer de toegang tot de repository;

Ga terug naar vorige versies;

Maak wijzigingen in behandeling - wijzigingen die niet direct aan de repository zijn toegevoegd, maar andere gebruikers ze kunnen zien, en u kunt deze wijzigingen alleen downloaden na speciale toestemming van de eigenaar van de wijzigingen;

Markeer individuele versies van bestanden in de repository en groepeer ze;

SQL Server 2005-databases worden gebruikt om gegevens en opslagplaatsen van ontwikkelde projecten op te slaan.

TFC is een krachtig en handig hulpmiddel waarmee u niet alleen broncodeversies kunt beheren, maar ook de volledige projectontwikkelingscyclus volledig kunt organiseren, van het schrijven van programma's tot hun documentatie. Dit krachtige en complexe systeem is echter meer geschikt voor het uitvoeren van grote projecten waarvoor een complex en grondig ontwikkelingsbeheer vereist is. Als je een kleine ontwikkeling hebt, is het logisch om een \u200b\u200bminder krachtig hulpmiddel te gebruiken, en nog beter vrij verspreid, omdat dit je tijd, geld en zenuwen bespaart.

  Generalisatie.

Met een grote selectie versiebeheersystemen kunt u aan alle eisen voldoen en het werk naar wens organiseren. Onder de hele variëteit aan systemen zijn er echter duidelijke leiders. Dus, als je een enorm project moet beheren, bestaande uit tienduizenden bestanden en waar duizenden mensen aan werken, dan is het het beste om de keuze op Git of Mercurial te stoppen. Als het belangrijkste voor u een handige interface is en het project in ontwikkeling niet erg groot is, dan heeft het Bazaar-systeem de voorkeur voor u.

Voor enkele programmeurs of kleine projecten die niet hoeven te worden vertakt en meerdere versies moeten worden gemaakt, is Subversion het beste.

Maar uiteindelijk is de keuze een kwestie van smaak, aangezien er nu veel versiebeheersystemen zijn die u alles geven wat u nodig heeft. Dus kies en u zult er geen spijt van krijgen. Versiebeheersystemen zijn absoluut noodzakelijke software voor elke ontwikkelaar en niet alleen.

Versiebeheersysteem ( Versiebeheersysteem, VCS) is software waarmee u wijzigingen in documenten kunt volgen, indien nodig kunt terugdraaien, kunt bepalen wie correcties heeft aangebracht en wanneer, enz. Het artikel gaat in op de typen Vcs, principes van hun werk, evenals voorbeelden van softwareproducten.

Wat is een versiebeheersysteem?

Waarschijnlijk is iedereen bekend met de situatie waarin het nodig is om bij het werken aan een project wijzigingen aan te brengen, maar u moet een werkbare optie behouden, in dit geval wordt in de regel een nieuwe map gemaakt, waarvan de naam waarschijnlijk "Nieuwe map" zal zijn met een toevoeging in de vorm van een datum of een kleine opmerking, de werkende versie van het project wordt erin gekopieerd en er wordt al mee gewerkt. In de loop van de tijd kan het aantal van dergelijke mappen aanzienlijk toenemen, wat het moeilijk maakt om terug te gaan naar eerdere versies, wijzigingen bij te houden, enz. Deze situatie wordt erger wanneer meerdere mensen aan een project werken.

Om dergelijke problemen op te lossen, wordt het versiebeheersysteem gebruikt, waarmee u comfortabel aan het project kunt werken, zowel individueel als in teamverband. Vcs  bewaakt wijzigingen in bestanden, biedt mogelijkheden voor het maken van nieuwe en samenvoegen van bestaande projectvertakkingen, beheert de toegang van gebruikers tot het project, stelt u in staat correcties terug te draaien en te bepalen wie, wanneer en welke wijzigingen in het project zijn aangebracht. Hoofdconcept Vcs  is de repository ( opslagplaats) - een speciale opslagplaats van projectbestanden en -mappen, waarin wijzigingen worden bijgehouden. De ontwikkelaar heeft een zogenaamde "werkkopie" ( werkkopie) van het project waarmee hij rechtstreeks samenwerkt. De werkkopie moet periodiek worden gesynchroniseerd met de repository, deze bewerking omvat het verzenden van wijzigingen die de gebruiker heeft aangebracht in zijn werkkopie (deze bewerking wordt begaan) en het bijwerken van de werkkopie, waarbij de laatste versie wordt gedownload van de repository naar de gebruiker (dit proces wordt aangeroepen.) bijwerken).

Gecentraliseerde en gedistribueerde versiebeheersystemen

Versiebeheersystemen kunnen in twee groepen worden verdeeld: gedistribueerd en gecentraliseerd.

Gecentraliseerde versiebeheersystemen

Gecentraliseerd  versiebeheersystemen zijn client-servertoepassingen, wanneer de projectrepository in één exemplaar bestaat en op de server wordt opgeslagen. Toegang tot het werd uitgevoerd via een speciale clienttoepassing.Voorbeelden van dergelijke softwareproducten zijn CVS, Subversie.

CVS (Gelijktijdig versiesysteem, Een systeem van gelijktijdige versies) is een van de eerste systemen die veel wordt gebruikt door ontwikkelaars; het is eind jaren 80 van de vorige eeuw ontstaan. Momenteel ontwikkelt dit product zich niet, het wordt voornamelijk geassocieerd met een aantal belangrijke tekortkomingen, zoals het onvermogen om bestanden te hernoemen, hun inefficiënte opslag en het bijna volledige gebrek aan integriteitscontrole.

Subversie (Svn) - een versiebeheersysteem dat is gemaakt om te vervangen CVS. Svn  is ontwikkeld in 2004 en is nog steeds in gebruik. Ondanks vele voordelen boven CVS  Bij Svn  er zijn nog steeds nadelen, zoals problemen met het hernoemen, het onvermogen om gegevens uit de repository te verwijderen, problemen bij het samenvoegen van branches, enz. Over het algemeen Svn  was (en blijft) een significante verbetering ten opzichte van CVS

Gedistribueerde versiebeheersystemen

Gedistribueerde versiebeheersystemen ( Gedistribueerd versiebeheersysteem, DVCS) kunt u de repository (de kopie) opslaan voor elke ontwikkelaar die met dit systeem werkt. Tegelijkertijd is het mogelijk om een \u200b\u200bcentrale repository (voorwaardelijk) toe te wijzen waarnaar wijzigingen van lokale worden verzonden en daarmee worden deze lokale repositories gesynchroniseerd. Bij het werken met een dergelijk systeem synchroniseren gebruikers periodiek hun lokale repositories met de centrale en werken ze rechtstreeks met hun lokale kopie. Nadat er voldoende wijzigingen zijn aangebracht in de lokale kopie, worden deze (wijzigingen) naar de server gestuurd. Bovendien wordt de server meestal voorwaardelijk geselecteerd, omdat in de meeste DVCSer bestaat niet zoiets als een "dedicated server met een centrale repository".

Een groot voordeel van deze aanpak is de autonomie van de ontwikkelaar bij het werken aan het project, de flexibiliteit van het totale systeem en de verhoogde betrouwbaarheid, omdat elke ontwikkelaar een lokale kopie van de centrale repository heeft. De twee bekendste DVCS  - deze Git  en Mercurial.

Beginnen met Mercurial, dit systeem is gratis DVCS, die zo is gebouwd dat het concept van een centrale repository ontbreekt, om hiermee te werken Vcs  gebruikt (meestal) console-hulpprogramma hg. Mercurial  Het heeft alle kenmerken van een versiebeheersysteem, zoals vertakken, samenvoegen, synchroniseren met andere repositories. Dit project wordt gebruikt en ondersteund door een groot aantal grote ontwikkelaars, waaronder Mozilla, Open kantoor, Openjdk  en vele anderen. Het product zelf is geschreven in de taal Python  en is beschikbaar op de meeste moderne besturingssystemen ( ramen, Mac OS, Linux), zijn er ook een groot aantal GUI-hulpprogramma's om mee te werken Mercurial. Belangrijkste concurrent Mercurial  op de markt voor gedistribueerde versiebeheersystemen is Gitdie tot op heden de leiderschapsrace heeft gewonnen.

Git  - gedistribueerd versiebeheersysteem ontwikkeld door Linus Torvaldsem om te werken aan de kernel van het besturingssysteem Linux. Een van de grote projecten waaronder het wordt gebruikt gitkunt u de kern selecteren Linux, Qt, Android. Git  gratis en met licentie GNU GPL  2 en ook MercurialBeschikbaar op bijna alle besturingssystemen. Volgens de basismogelijkheden git  gelijkwaardig aan Mercurial  (en anderen DVCS), maar dankzij een aantal voordelen (hoge snelheid, de mogelijkheid om met anderen te integreren) Vcs, gebruiksvriendelijke interface) en de zeer actieve gemeenschap die zich rond dit systeem heeft gevormd, git  werd de leider op de markt van gedistribueerde versiebeheersystemen.Opgemerkt moet worden dat ondanks de grote populariteit van dergelijke systemen als gitgrote bedrijven zoals Googlegebruik hun Vcs.

Dit was een inleidende lezing over versiebeheersystemen. Verder betreft de hele presentatie alleen git.

Als je meer wilt leer van videocolleges, dan raden we een klassikale cursus aan git  van Geekbrains ga naar de link  en zoek de cursus in de sectie 'Cursussen' “Git. Snelle start".   is hij vrijhoeft u zich alleen op de site te registreren. We raden je aan om deze bron eens nader te bekijken, er staan \u200b\u200bnog veel interessante dingen op!