Difference between revisions of "Manual Subversion"
| Line 10: | Line 10: | ||
Als meerdere mensen aan dezelfde bestanden werken, kan het probleem ontstaan dat meerderen hetzelfde bestand hebben uitgecheckt, tegelijkertijd wijzigingen aanbrengen, en die vervolgens willen inchecken. Bij de eerste gebruiker (in het plaatje hierna bij Sally) gaat dat goed; bij de tweede gebruiker (Harry) gaat het verkeerd. Hij krijgt een ‘out-of-date’-error. De oplossing is dat Harry eerst de wijzigingen van Sally in zijn versie incorporeert (update), en dan pas zijn wijzigingen terugschrijft naar de repository. Wanneer Sally’s wijzigingen in een ander deel van het bestand zijn dan die van Harry, zal het systeem in staat zijn om beide sets wijzigingen in Harry’s bestand aan te brengen. Na de update kan Harry alsnog inchecken (en kan Sally updaten om ook Harry’s wijzigingen binnen te krijgen). | Als meerdere mensen aan dezelfde bestanden werken, kan het probleem ontstaan dat meerderen hetzelfde bestand hebben uitgecheckt, tegelijkertijd wijzigingen aanbrengen, en die vervolgens willen inchecken. Bij de eerste gebruiker (in het plaatje hierna bij Sally) gaat dat goed; bij de tweede gebruiker (Harry) gaat het verkeerd. Hij krijgt een ‘out-of-date’-error. De oplossing is dat Harry eerst de wijzigingen van Sally in zijn versie incorporeert (update), en dan pas zijn wijzigingen terugschrijft naar de repository. Wanneer Sally’s wijzigingen in een ander deel van het bestand zijn dan die van Harry, zal het systeem in staat zijn om beide sets wijzigingen in Harry’s bestand aan te brengen. Na de update kan Harry alsnog inchecken (en kan Sally updaten om ook Harry’s wijzigingen binnen te krijgen). | ||
| − | [[File:Afb_1.1.png | + | [[File:Afb_1.1.png]] |
| Line 21: | Line 21: | ||
| − | [[File:Afb_3.jpg | + | [[File:Afb_3.jpg]] |
==Het definiëren van een repository-locatie en het maken van een werkkopie== | ==Het definiëren van een repository-locatie en het maken van een werkkopie== | ||
| Line 27: | Line 27: | ||
Hiervoor activeren we de repositories view. Vervolgens definiëren we een nieuwe repositorylocatie, als volgt: | Hiervoor activeren we de repositories view. Vervolgens definiëren we een nieuwe repositorylocatie, als volgt: | ||
| − | [[File:Afb_4.jpg | + | [[File:Afb_4.jpg]] |
Geef vervolgens de gewenste netwerklocatie van de repository op: | Geef vervolgens de gewenste netwerklocatie van de repository op: | ||
| − | [[File:Afb_5.jpg | + | [[File:Afb_5.jpg]] |
En vul de juiste gebruiker en wachtwoord in (raadpleeg hiervoor eventueel Ramona): | En vul de juiste gebruiker en wachtwoord in (raadpleeg hiervoor eventueel Ramona): | ||
| − | [[File:Afb_6.jpg | + | [[File:Afb_6.jpg]] |
De client definieert nu de repository locatie. | De client definieert nu de repository locatie. | ||
| Line 41: | Line 41: | ||
De volgende stap is het aanmaken van een werkkopie. Daarvoor selecteren we in de repository de gewenste map, doen een rechtermuisklik en kiezen voor ‘Check uit’: | De volgende stap is het aanmaken van een werkkopie. Daarvoor selecteren we in de repository de gewenste map, doen een rechtermuisklik en kiezen voor ‘Check uit’: | ||
| − | [[File:Afb_7.jpg | + | [[File:Afb_7.jpg]] |
Er wordt vervolgens gevraagd waar we de werkkopie op schijf willen opslaan: | Er wordt vervolgens gevraagd waar we de werkkopie op schijf willen opslaan: | ||
| − | [[File:Afb_8.jpg | + | [[File:Afb_8.jpg]] |
Kies een map op de harde schijf van je PC. Na herhaaldelijk bevestigen wordt de inhoud van de map op schijf geplaatst. Nu heb je dus een eigen kopie van de bestanden uit de repository. | Kies een map op de harde schijf van je PC. Na herhaaldelijk bevestigen wordt de inhoud van de map op schijf geplaatst. Nu heb je dus een eigen kopie van de bestanden uit de repository. | ||
| Line 64: | Line 64: | ||
Voor een update: rechtermuisklik en kies voor update: | Voor een update: rechtermuisklik en kies voor update: | ||
| − | [[File:Afb_9.jpg | + | [[File:Afb_9.jpg]] |
Voor verversen: rechtermuisklik en kies voor Ververs: | Voor verversen: rechtermuisklik en kies voor Ververs: | ||
| − | [[File:Afb_10. | + | [[File:Afb_10.jpg]] |
Na het verversen toont de client door middel van een sterretje welke bestanden en mappen zijn gewijzigd: | Na het verversen toont de client door middel van een sterretje welke bestanden en mappen zijn gewijzigd: | ||
| − | [[File:Afb_11.jpg | + | [[File:Afb_11.jpg]] |
Om de wijzigingen in te checken: rechtermuisklik op map of bestand en kies voor Check in: | Om de wijzigingen in te checken: rechtermuisklik op map of bestand en kies voor Check in: | ||
| − | [[File:Afb_12.jpg | + | [[File:Afb_12.jpg]] |
Vul vervolgens een korte toelichting in (dan weet je nog een beetje wat er gebeurd is mocht je ooit de geschiedenis van een bestand moeten nagaan) : | Vul vervolgens een korte toelichting in (dan weet je nog een beetje wat er gebeurd is mocht je ooit de geschiedenis van een bestand moeten nagaan) : | ||
| − | [[File:Afb_13.jpg | + | [[File:Afb_13.jpg]] |
Het systeem brengt nu de bestanden over naar de repository. De cyclus kan opnieuw beginnen. | Het systeem brengt nu de bestanden over naar de repository. De cyclus kan opnieuw beginnen. | ||
| Line 89: | Line 89: | ||
Zoals aan de aanvang van dit document is toegelicht, is het mogelijk dat twee gebruikers eenzelfde bestand in onderhoud hebben. De eerste gebruiker checkt wijzigingen in, zonder probleem. Als de tweede gebruiker zijn wijzigingen incheckt, protesteert het systeem met een out-of-date message: | Zoals aan de aanvang van dit document is toegelicht, is het mogelijk dat twee gebruikers eenzelfde bestand in onderhoud hebben. De eerste gebruiker checkt wijzigingen in, zonder probleem. Als de tweede gebruiker zijn wijzigingen incheckt, protesteert het systeem met een out-of-date message: | ||
| − | [[File:Afb_14.jpg | + | [[File:Afb_14.jpg]] |
De oplossing is in het algemeen eenvoudig: de tweede gebruiker haalt alsnog de wijzigingen binnen van de server (d.m.v. Update) en kan daarna alsnog inchecken. Dit gaat echter alleen goed wanneer het systeem de beide sets wijzigingen kan samenvoegen. Wanneer het systeem dat niet kan, markeert het de versie van gebruiker twee als ‘in conflict’. Het ‘C’—icoontje op het plaatje hierna geeft aan dat het betreffende bestand in conflict-status is. Het systeem maakt een aantal extra bestanden om te helpen het probleem op te lossen. De bestanden met de extensie ‘.rnnnn’ geven de oude, ongewijzigde versie van het bestand en de nieuwste versie (volgens de repository). De versie ‘.mine’ geeft de versie met wijzigingen van gebruiker 2: | De oplossing is in het algemeen eenvoudig: de tweede gebruiker haalt alsnog de wijzigingen binnen van de server (d.m.v. Update) en kan daarna alsnog inchecken. Dit gaat echter alleen goed wanneer het systeem de beide sets wijzigingen kan samenvoegen. Wanneer het systeem dat niet kan, markeert het de versie van gebruiker twee als ‘in conflict’. Het ‘C’—icoontje op het plaatje hierna geeft aan dat het betreffende bestand in conflict-status is. Het systeem maakt een aantal extra bestanden om te helpen het probleem op te lossen. De bestanden met de extensie ‘.rnnnn’ geven de oude, ongewijzigde versie van het bestand en de nieuwste versie (volgens de repository). De versie ‘.mine’ geeft de versie met wijzigingen van gebruiker 2: | ||
| − | [[File:Afb_15.jpg | + | [[File:Afb_15.jpg]] |
In het bestand met de originele naam (hier test.xml) zijn de conflicterende wijzigingen beide opgenomen: | In het bestand met de originele naam (hier test.xml) zijn de conflicterende wijzigingen beide opgenomen: | ||
| − | [[File:Afb_16.jpg | + | [[File:Afb_16.jpg]] |
Het is aan de gebruiker om deze conflicten op te lossen. Nadat de gewenste aanpassingen zijn aangebracht kan in de client worden aangegeven dat het conflict is opgelost. Het systeem ruimt dan de tijdelijke bestanden op, het bestand kan worden ingecheckt en ook door gebruiker 1 worden uitgecheckt: | Het is aan de gebruiker om deze conflicten op te lossen. Nadat de gewenste aanpassingen zijn aangebracht kan in de client worden aangegeven dat het conflict is opgelost. Het systeem ruimt dan de tijdelijke bestanden op, het bestand kan worden ingecheckt en ook door gebruiker 1 worden uitgecheckt: | ||
| − | [[File:Afb_17.png | + | [[File:Afb_17.png]] |
Om deze situatie te vermijden is het wenselijk om af te spreken niet in dezelfde delen van een document te werken, en regelmatig (tenminste dagelijks, maar liever vaker) in te checken en te updaten. | Om deze situatie te vermijden is het wenselijk om af te spreken niet in dezelfde delen van een document te werken, en regelmatig (tenminste dagelijks, maar liever vaker) in te checken en te updaten. | ||
Revision as of 17:06, 19 January 2017
[plaatjes toevoegen]
De Subversion (ook: SVN) repository is een centrale lokatie op het netwerk waar we bestanden (bijvoorbeeld XML-bestanden) bewaren. In de XML Editor die we gebruiken, oXygen, zit een Subversion client ingebouwd, een hulpprogramma dat met de repository kan omgaan. We gebruiken die client om bestanden heen en weer te halen vanaf de server naar de eigen computer. In deze handleiding wordt beschreven hoe e.e.a. werkt. De screenshots in deze handleiding zijn gebaseerd op oXygen 12.2.
Contents
Terminologie en basiswerkwijze
De repository is de centrale locatie op de server. Op de eigen PC wordt een werkkopie gemaakt van de repository, of een deel daarvan. Het maken van zo’n werkkopie heet uitchecken uit de repository. De bestanden in de werkkopie kunnen worden gewijzigd, en in ons geval zal dat meestal gebeuren met oXygen. Door het verversen van de werkkopie wordt de Subversion client er op geattendeerd dat er bestanden zijn gewijzigd. Dat is niet altijd nodig. Bij het openen van een werkkopie checkt de client sowieso of er bestanden zijn gewijzigd, toegevoegd of verwijderd in de werkkopie. Een gewijzigd bestand kun je terugzetten in de repository. Die handeling heet check in. Bij de check in wordt je gevraagd om een korte toelichting te geven. Bij het dagelijks werk aan de bestanden zul je eerst de bestanden in je werkkopie updaten naar de laatste versie: je haalt dan uit de repository de laatste wijzigingen voor je bestanden. Vervolgens bewerk je de bestanden, en checkt de gewijzigde inhoud in. Voordat je verder werkt aan de bestanden kijk je altijd even of er nog wijzigingen zijn die door anderen zijn aangebracht (update). Als meerdere mensen aan dezelfde bestanden werken, kan het probleem ontstaan dat meerderen hetzelfde bestand hebben uitgecheckt, tegelijkertijd wijzigingen aanbrengen, en die vervolgens willen inchecken. Bij de eerste gebruiker (in het plaatje hierna bij Sally) gaat dat goed; bij de tweede gebruiker (Harry) gaat het verkeerd. Hij krijgt een ‘out-of-date’-error. De oplossing is dat Harry eerst de wijzigingen van Sally in zijn versie incorporeert (update), en dan pas zijn wijzigingen terugschrijft naar de repository. Wanneer Sally’s wijzigingen in een ander deel van het bestand zijn dan die van Harry, zal het systeem in staat zijn om beide sets wijzigingen in Harry’s bestand aan te brengen. Na de update kan Harry alsnog inchecken (en kan Sally updaten om ook Harry’s wijzigingen binnen te krijgen).
Het is ook mogelijk dat het systeem de beide bestanden niet kan ‘mergen’, omdat de wijzigingen te dicht bij elkaar zitten. In dat geval markeert het Harry’s bestand als in conflict. Harry moet dan zelf het conflict oplossen: ervoor zorgen dat een versie van het bestand ontstaat waar aan beide wijzigingen recht wordt gedaan. Hierover verderop meer.
De subversion client
De oXygen Subversion client wordt gestart vanuit de editor, menu Extra, optie SVN-client. In de client wordt eerst (eenmalig) de repository gedefinieerd en een werkkopie aangemaakt. In het dagelijks gebruik worden met behulp van de SVN client de bestanden heen en weer gestuurd van en naar de server. De client heeft meerdere ‘view’s. De belangrijkste views zijn de repositories view en de werkkopie view. Zie plaatje hierna:
Het definiëren van een repository-locatie en het maken van een werkkopie
Hiervoor activeren we de repositories view. Vervolgens definiëren we een nieuwe repositorylocatie, als volgt:
Geef vervolgens de gewenste netwerklocatie van de repository op:
En vul de juiste gebruiker en wachtwoord in (raadpleeg hiervoor eventueel Ramona):
De client definieert nu de repository locatie.
De volgende stap is het aanmaken van een werkkopie. Daarvoor selecteren we in de repository de gewenste map, doen een rechtermuisklik en kiezen voor ‘Check uit’:
Er wordt vervolgens gevraagd waar we de werkkopie op schijf willen opslaan:
Kies een map op de harde schijf van je PC. Na herhaaldelijk bevestigen wordt de inhoud van de map op schijf geplaatst. Nu heb je dus een eigen kopie van de bestanden uit de repository.
De bewerking van bestanden
Het bewerken van bestanden verloopt in een vaste cyclus:
- Update – haal de laatste wijzigingen van de server binnen
- Bewerk – breng de wijzigingen aan via de editor
- (evt.) Ververs – breng de SVN client van de wijzigingen op de hoogte
- Check in – breng de wijzigingen aan op de server
- Update – haal de laatste wijzigingen van de server binnen
- …
De update en check-in kun je op het niveau van een hele map doen, maar ook op het niveau van een enkel bestand.
Voor een update: rechtermuisklik en kies voor update:
Voor verversen: rechtermuisklik en kies voor Ververs:
Na het verversen toont de client door middel van een sterretje welke bestanden en mappen zijn gewijzigd:
Om de wijzigingen in te checken: rechtermuisklik op map of bestand en kies voor Check in:
Vul vervolgens een korte toelichting in (dan weet je nog een beetje wat er gebeurd is mocht je ooit de geschiedenis van een bestand moeten nagaan) :
Het systeem brengt nu de bestanden over naar de repository. De cyclus kan opnieuw beginnen.
Het afhandelen van conflicterende wijzigingen
Zoals aan de aanvang van dit document is toegelicht, is het mogelijk dat twee gebruikers eenzelfde bestand in onderhoud hebben. De eerste gebruiker checkt wijzigingen in, zonder probleem. Als de tweede gebruiker zijn wijzigingen incheckt, protesteert het systeem met een out-of-date message:
De oplossing is in het algemeen eenvoudig: de tweede gebruiker haalt alsnog de wijzigingen binnen van de server (d.m.v. Update) en kan daarna alsnog inchecken. Dit gaat echter alleen goed wanneer het systeem de beide sets wijzigingen kan samenvoegen. Wanneer het systeem dat niet kan, markeert het de versie van gebruiker twee als ‘in conflict’. Het ‘C’—icoontje op het plaatje hierna geeft aan dat het betreffende bestand in conflict-status is. Het systeem maakt een aantal extra bestanden om te helpen het probleem op te lossen. De bestanden met de extensie ‘.rnnnn’ geven de oude, ongewijzigde versie van het bestand en de nieuwste versie (volgens de repository). De versie ‘.mine’ geeft de versie met wijzigingen van gebruiker 2:
In het bestand met de originele naam (hier test.xml) zijn de conflicterende wijzigingen beide opgenomen:
Het is aan de gebruiker om deze conflicten op te lossen. Nadat de gewenste aanpassingen zijn aangebracht kan in de client worden aangegeven dat het conflict is opgelost. Het systeem ruimt dan de tijdelijke bestanden op, het bestand kan worden ingecheckt en ook door gebruiker 1 worden uitgecheckt:
Om deze situatie te vermijden is het wenselijk om af te spreken niet in dezelfde delen van een document te werken, en regelmatig (tenminste dagelijks, maar liever vaker) in te checken en te updaten.
