Manual Subversion - Revision history

ASC: /* =See also */

2017-01-31T15:18:19Z

‎=See also

ASC at 09:47, 25 January 2017

2017-01-25T09:47:42Z

ASC at 09:47, 25 January 2017

2017-01-25T09:47:07Z

ASC at 16:06, 19 January 2017

2017-01-19T16:06:28Z

ASC at 16:05, 19 January 2017

2017-01-19T16:05:24Z

ASC at 16:04, 19 January 2017

2017-01-19T16:04:39Z

ASC at 16:04, 19 January 2017

2017-01-19T16:04:11Z

ASC at 14:31, 19 January 2017

2017-01-19T14:31:38Z

ASC at 14:23, 19 January 2017

2017-01-19T14:23:54Z

ASC at 14:22, 19 January 2017

2017-01-19T14:22:37Z

@@ Line 99: / Line 99: @@
 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.
-==See also=
+==See also==
 * [[Manual oXygen]]
 [[Category:XML Huygens]]
 [[Category:Manuals]]

@@ Line 17: / Line 17: @@
 De client heeft meerdere ‘view’s. De belangrijkste views zijn de repositories view en de werkkopie view. Zie plaatje hierna:
- [[File:Afb_3.jpg]]
+[[File:Afb_3.jpg]]
 ==Het definiëren van een repository-locatie en het maken van een werkkopie==

@@ Line 1: / Line 1: @@
 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.
@@ Line 11: / Line 9: @@
 [[File:Afb_1.1.png]]
 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.
@@ Line 20: / Line 17: @@
 De client heeft meerdere ‘view’s. De belangrijkste views zijn de repositories view en de werkkopie view. Zie plaatje hierna:
   [[File:Afb_3.jpg]]
 [[File:Afb_3.jpg]]
 ==Het definiëren van een repository-locatie en het maken van een werkkopie==
@@ Line 48: / Line 44: @@
 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==
@@ Line 83: / Line 78: @@
 Het systeem brengt nu de bestanden over naar de repository. De cyclus kan opnieuw beginnen.
 ==Het afhandelen van conflicterende wijzigingen==

@@ 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).
-[[File:Afb_1.1.png|frame|left]]
+[[File:Afb_1.1.png]]
@@ Line 21: / Line 21: @@
-[[File:Afb_3.jpg|frame]]
+[[File:Afb_3.jpg]]
 ==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:
-[[File:Afb_4.jpg|frame]]
+[[File:Afb_4.jpg]]
 Geef vervolgens de gewenste netwerklocatie van de repository op:
-[[File:Afb_5.jpg|frame]]
+[[File:Afb_5.jpg]]
 En vul de juiste gebruiker en wachtwoord in (raadpleeg hiervoor eventueel Ramona):
-[[File:Afb_6.jpg|frame]]
+[[File:Afb_6.jpg]]
 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’:
-[[File:Afb_7.jpg|frame]]
+[[File:Afb_7.jpg]]
 Er wordt vervolgens gevraagd waar we de werkkopie op schijf willen opslaan:
-[[File:Afb_8.jpg|frame]]
+[[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.
@@ Line 64: / Line 64: @@
 Voor een update: rechtermuisklik en kies voor update:
-[[File:Afb_9.jpg|frame]]
+[[File:Afb_9.jpg]]
 Voor verversen: rechtermuisklik en kies voor Ververs:
-[[File:Afb_10.jp|frame]]
+[[File:Afb_10.jpg]]
 Na het verversen toont de client door middel van een sterretje welke bestanden en mappen zijn gewijzigd:
-[[File:Afb_11.jpg|frame]]
+[[File:Afb_11.jpg]]
 Om de wijzigingen in te checken: rechtermuisklik op map of bestand en kies voor Check in:
-[[File:Afb_12.jpg|frame]]
+[[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) :
-[[File:Afb_13.jpg|frame]]
+[[File:Afb_13.jpg]]
 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:
-[[File:Afb_14.jpg|frame]]
+[[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:
-[[File:Afb_15.jpg|frame]]
+[[File:Afb_15.jpg]]
 In het bestand met de originele naam (hier test.xml) zijn de conflicterende wijzigingen beide opgenomen:
-[[File:Afb_16.jpg|frame]]
+[[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:
-[[File:Afb_17.png|frame]]
+[[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.

@@ Line 21: / Line 21: @@
-[[File:Afb_3.jpg]]
+[[File:Afb_3.jpg|frame]]
 ==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:
-[[File:Afb_4.jpg]]
+[[File:Afb_4.jpg|frame]]
 Geef vervolgens de gewenste netwerklocatie van de repository op:
-[[File:Afb_5.jpg]]
+[[File:Afb_5.jpg|frame]]
 En vul de juiste gebruiker en wachtwoord in (raadpleeg hiervoor eventueel Ramona):
-[[File:Afb_6.jpg]]
+[[File:Afb_6.jpg|frame]]
 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’:
-[[File:Afb_7.jpg]]
+[[File:Afb_7.jpg|frame]]
 Er wordt vervolgens gevraagd waar we de werkkopie op schijf willen opslaan:
-[[File:Afb_8.jpg]]
+[[File:Afb_8.jpg|frame]]
 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:
-[[File:Afb_9.jpg]]
+[[File:Afb_9.jpg|frame]]
 Voor verversen: rechtermuisklik en kies voor Ververs:
-[[File:Afb_10.jpg]]
+[[File:Afb_10.jp|frame]]
 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|frame]]
 Om de wijzigingen in te checken: rechtermuisklik op map of bestand en kies voor Check in:
-[[File:Afb_12.jpg]]
+[[File:Afb_12.jpg|frame]]
 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|frame]]
 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:
-[[File:Afb_14.jpg]]
+[[File:Afb_14.jpg|frame]]
 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|frame]]
 In het bestand met de originele naam (hier test.xml) zijn de conflicterende wijzigingen beide opgenomen:
-[[File:Afb_16.jpg]]
+[[File:Afb_16.jpg|frame]]
 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|frame]]
 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.

← Older revision		Revision as of 16:04, 19 January 2017
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\|frame]]	+	[[File:Afb_1.1.png\|frame\|left]]

← Older revision		Revision as of 14:31, 19 January 2017
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.png]]	+	[[File:Afb_1.1.png]]