Results 1 to 5 of 5

Thread: Versiebeheer 1: Introductie

  1. #1

    Versiebeheer 1: Introductie

    Inleiding
    Versiebeheer is een must voor programmeurs. Toch gebruiken veel programmeurs het nog steeds niet. Het lijkt ingewikkeld en omslachtig; iets dat veel tijd vergt en weinig oplevert.

    Maar gelukkig is dat niet zo. Versiebeheer is eenvoudig, kost nauwelijks tijd en heeft heel veel voordelen.

    In deze serie artikelen wil ik je kennis laten maken met versiebeheer. De serie bestaat uit:

    1. Introductie. Een algemene uitleg van wat er zoal te krijgen is. (zie onder)
    2. Mercurial in je eentje. Een inleidend artikel over Mercurial.
    3. (In ontwikkeling) Mercurial voor een team. De extra stappen die nodig zijn voor samenwerking.

    Hopelijk kan ik (of iemand anders) de serie uitbreiden met artikelen over andere versiebeheersystemen of met een artikel ‘Mercurial voor gevorderden’ waarin concepten als Branching en Shelving worden uitgediept.

    Laat je niet afschrikken door de hoeveelheid tekst. Ik ben lang van stof en graag volledig, maar geloof me, het is echt niet moeilijk!

    Reacties op deze serie kun je kwijt in deze thread.
    Last edited by GolezTrol; 06-Dec-12 at 11:42.
    1+1=b

  2. #2

    Waarom versiebeheer

    Waarom versiebeheer
    Wie kent niet de volgende systemen:
    • Een mapje ‘oud’, en dan een mapje ‘ouder’, ‘minder oud’, ‘oud2’, ‘oud_kan_weg’....
      In die valkuil zijn we allemaal weleens gestapt, maar weet je later nog wat er in die kopie stond? Je wilt niet teveel mapjes, dus kopiëer je het maar niet te vaak, en als je het nodig hebt, blijkt dat je net niets zinnigs hebt opgeslagen.
    • Meer structuur: Mapjes met de naam ‘ProjectX YYYYMMDD’.
      Werkt op zich redelijk, maar kun je je nog herinneren wanneer je een bepaalde aanpassing hebt gedaan?
    • Dagelijkse backup van de projectmap.
      Dat kan, maar backups kun je vaak niet makkelijk terugzetten. Selectief terugzetten van een enkel bestand is nog lastiger, en welke backup moet je hebben?
    • De ‘__history’ map die Delphi maakt.
      Deze geschiedenis loopt maar een klein stukje terug. Elke keer als je een bestand opslaat wordt er een kopie van het bestand in deze map gezet, met een bepaald maximum (standaard 10). Deze functionaliteit is wel nuttig voor plotselinge fouten die je snel ontdekt, zoals het per ongeluk verwijderen of overschrijven van een unit, maar niet voor het terughalen van een vroegere aanpassing.


    Wat versiebeheer biedt is:
    • Een fijnmazige geschiedenis, waarin je nauwkeurig kunt terugvinden wie wat wanneer heeft gedaan. En waarom.
    • Tools voor praktisch samenwerken (o.a. samenvoegen van code)
    • Alles van lokaal of een eigen server tot opslag in de ‘cloud’. Eenvoudig om de versie-database (repository) mee te nemen in je eigen backups.


    In de volgende hoofdstukken probeer ik wat licht te laten schijnen in de duisternis en je op gang te helpen met versiebeheer.
    Last edited by GolezTrol; 19-Sep-12 at 10:54.
    1+1=b

  3. #3

    Terminologie

    Terminologie
    Het doel van versiebeheer is -zoals de naam al zegt- het beheren van versies. Versies van je source code om precies te zijn.

    Het beheren van versies doe je uiteraard in een versiebeheersysteem of VCS (Version Control System) of SCM tool (Source Control Management). Zo'n database van files met alle wijzigingen noem je doorgaans een repository.
    Bewerken van bestanden doe je in je werkkopie (Working copy). In deze lokale kopie kun je rommelen wat je wilt. De wijzigingen zijn nog niet opgeslagen in het versiebeheersysteem en kun je nog terugdraaien.

    Als je klaar bent met je aanpassingen kun je de wijzigingen uploaden naar de repository. Dit process wordt doorgaans 'commit' genoemd. Andere gebruikers kunnen deze wijziging nu weer downloaden naar hun lokale werkkopie (update).

    Termen
    Even wat basistermen op een rijtje. Leer ze niet allemaal uit je hoofd, de meeste spreken sowieso voor zich, en sommige ervan zul je misschien nooit gebruiken. Slechts enkele hiervan komen in de eerste artikelen naar voren.

    • Branch (of Fork) - een vertakking in de source code, zodat je verschillende commits nog uit elkaar kunt houden, bijvoorbeeld wanneer je werkt aan een deelproject dat pas met de trunk gemerged mag worden als het af is.
    • Checkout (Check-out) - Het maken van een lokale working copy van de repository.
    • Commit (of Check-in) - Het doorvoeren van je lokale wijzigingen in de repository.
    • Conflict - Een botsing tijdens het uitvoeren van de commit. Als een andere gebruiker een wijziging heeft gedaan in hetzelfde bestand, en het systeem kan dit niet automatisch oplossen, dan moet de committende gebruiker handmatig de verschillen uitpluizen en samenvoegen.
    • Head - De meest recente commit, ofwel de 'laatste versie'.
    • Merge - Het samenvoegen van verschillende wijzigingen in een bestand of een set bestanden. Vaak lukt dit automatisch. Lukt dat niet, dan is er een conflict.
    • Push/PullCommits van de ene repository kopiëren naar een andere (bij distributed versiebeheer)
    • Repository - De plaats waar de huidige versie en alle historische gegevens van bestanden bewaard wordt.
    • Resolve/Resolving - Het (handmatig) oplossen van een conflict.
    • Revision (of Version) - een bepaalde versie van je repository. De Head is de meest recente revision.
    • Tag (of label) - Een markering van een belangrijk moment, bijvoorbeeld een grote release.
    • Trunk (soms ook baseline of mainline genoemd) - de 'stam' van een repository, ofwel de lijn die geen branch is.
    • Update (of Sync) - Het bijwerken van je working copy met wijzigingen in de repository.
    • Working copy - De lokale kopie van bestanden uit de repository. Hierin doe je je wijzigingen voordat je deze commit.


    In het hoofstuk na deze introductie leg ik uit wat het verschil is tussen een centraal en een decentraal versiebeheersysteem.
    Last edited by GolezTrol; 19-Sep-12 at 10:54.
    1+1=b

  4. #4

    Centralized vs Distributed

    Centralized vs Distributed/Decentralized
    Lees ook even de Inleiding en de Termenlijst hierboven.

    Er zijn twee soorten versiebeheersystemen:

    Centraal Versiebeheersysteem (Centralised VCS)
    Alle wijzigingen worden direct opgeslagen in een centrale repository. Dit is een client-server-systeem, waarbij alle versieinformatie op een server staat.

    Bekende centrale versiebeheersystemen zijn Visual Source Safe en SVN (Subversion).

    Decentraal Versiebeheersysteem (Decentralised VCS)
    Iedereen heeft een kopie (clone) van de repository met alle versieinformatie. Wijzigingen sla je op in je eigen clone. Deze ‘commits’ kunnen vervolgens gedupliceerd (push/pull) worden naar de clones van anderen.

    Bekende decentrale versiebeheersystemen zijn Git en Mercurial (Hg).

    Centraal Versiebeheersysteem (Centralised VCS)

    In dit type is er een centrale plaats waar de versies worden opgeslagen. Alle gebruikers van deze repository kunnen een bestand uit het versiebeheersysteem ophalen (check-out), wijzigen en weer committen (ook wel check-in).

    Name:  Centraal.png
Views: 1275
Size:  11.2 KB

    Voordeel: Locking

    Een voordeel van een centraal systeem boven een decentraal systeem, is dat je in een centraal systeem de mogelijkheid hebt om een bestand te locken. Je kunt als gebruiker een een bestand exclusief voor jezelf reserveren. Andere gebruikers kunnen/mogen het bestand niet wijzigen terwijl jij ermee bezig bent. Dit is met name nuttig voor binaire bestanden, zoals afbeeldingen en Office-documenten. Je executables en dcu's zijn ook binaire bestanden, maar die zet je doorgaans niet in versiebeheer. Alleen de source is vaak voldoende.
    Nadeel: Code delen kan maar via één kanaal. Werkt alleen als je verbinding hebt met de server.

    Een nadeel van zo'n enkele 'oerbron', is dat het soms lastig is om meerdere projecten naast elkaar te draaien. Wanneer je verschillende deelprojecten hebt in de ontwikkeling van dezelfde grote applicatie, wil je deze gescheiden kunnen houden tot zo'n deelproject is afgerond.

    SVN biedt daar wel wat mogelijkheden in, in de vorm van Branching, je kunt dan een branch, een vertakking maken van de source van je hoofdproject. Wijzigingen in deze branch blijven apart opgeslagen, maar toch binnen dezelfde respository. Op een bepaald moment kun je deze branch weer samenvoegen (merge) met de hoofdtak.

    Dat samenvoegen kan SVN grotendeels automatisch doen, al gaat dat helaas niet altijd helemaal lekker.

    Decentraal Versiebeheersysteem (Decentralised VCS)

    In dit type is er geen hoofdrepository, maar zijn er meerdere klonen (clones) van een respository. Een clone is een volledige kopie van de repository, met daarin de huidige versie van alle bestanden en een database met alle eerdere versies.

    Name:  Decentraal.png
Views: 1282
Size:  80.9 KB

    Voordeel: Committen zonder direct te delen. Committen werkt ook offline. Mergen gaat lokaal (en daardoor sneller).

    In een decentraal systeem kun je als gebruiker een clone maken van een repository vanaf een server, of van een andere gebruiker.

    Wijzigingen die je doet, doe je in jouw lokale kopie van de bestanden. Deze kun je committen naar jouw lokale repository. Je dus meerdere kleine wijzigingen afzonderlijk committen, nog voor je deze deelt met anderen. Zodoende kun je heel nauwgezet bijhouden welke wijzigingen je hebt gedaan, maar kun je toch de hele ontwikkeling van een nieuwe functionaliteit apart houden tot alle wijzigingen die daarvoor nodig zijn, zijn gedaan en zijn getest.

    Als het moment daar is, kun je de wijzigingen overzetten naar de repository van een ander. Dat kan door deze te duwen (push), of door ze vanuit de andere repository naar je toe te trekken (pull). In basis komt dit op hetzelfde neer. Het is maar net vanaf welke kant je het bekijkt.

    Wanneer je in teams werkt, is dit een handige opzet. Je persoonlijke wijzigingen kun je doorpushen naar al je teamgenoten. Wanneer alle wijzigingen zijn verzameld en een functionaliteit is afgerond, kan deze weer worden doorgepusht naar de leden van de andere teams.

    Toch centraliseren?

    Wie een dergelijke spreiding toch te onhandig vindt, kan ook een soort hiërarchie aanbrengen in de clones. Maak bijvoorbeeld een hoofdrepository op een server. Op diezelfde server kun je clones maken voor elk team. Elk teamlid kan daarvan weer een clone maken op zijn eigen ontwikkel-PC.

    Name:  Hierarchisch.png
Views: 1325
Size:  75.7 KB

    Wijzigingen kun je pushen naar de repository van het team. Elk teamlid kan daar zelf jouw wijzigingen weer uit ophalen (pull). Als je als team tevreden bent, kun je de gezamelijke wijzigingen weer pushen naar de hoofdrepository, waarna andere teams deze weer kunnen ophalen in hun gezamelijke clone en hun persoonlijke clones.

    Op die manier heb je eigenlijk een soort gecentraliseerde opzet, maar dan met een hiërarchische structuur. Voor ontwikkeling in teams is dit aanzienlijk handiger dan de branching mogelijkheden van SVN.

    De hiërarchie berust overigens vooral op afspraken tussen de teams. In technische zin is elke clone gelijkwaardig en kunnen wijzigingen tussen alle clones onderling gedeeld worden.


    Erg abstract? Sorry. Het volgende deel wordt concreter. Daarin laat ik zien hoe je een Mercurial-repository opzet en hierin bestanden kunt committen.
    Last edited by GolezTrol; 19-Sep-12 at 10:54.
    1+1=b

  5. #5

    Samenvatting

    Samenvatting
    Versiebeheer is een must. Het zorgt voor een gestructureerde en overzichtelijke manier om je wijzigingen in bij te houden, en daarmee voor een veilig gevoel.

    Er zijn globaal twee soorten versiebeheersystemen: Centraal en Decentraal of Distributed.

    Een Centraal systeem is een client-server-systeem, dat je alleen kunt gebruiken als je actieve toegang tot de server hebt. Het voordeel is dat je (binaire) bestanden kunt locken.

    Met een Distributed systeem heeft elk werkstation een eigen kopie van de bestandsgeschiedenis. Het voordeel is dat je werk kunt committen zonder netwerkverbinding en dat het samenvoegen van je werk met dat van collega's vaak makkelijker gaat.

    Versiebeheer is geen vervanging voor backups! Zorg dat je je repository nog steeds backupt! De noodzaak hiervoor is wel minder groot met een distributed versiebeheersysteem, omdat daarmee elke clone een volwaardige kopie is van de volledige geschiedenis van je project, maar toch...

    Vervolg
    Ga verder naar Deel twee: Mercurial in je eentje
    Last edited by GolezTrol; 11-Oct-13 at 10:05.
    1+1=b

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •