Zo af en toe zul je tegen een conflict aanlopen als je bestanden in het archief ververst of samenvoegt, of als je je werkkopie omschakelt naar een andere URL. Er zijn twee soorten conflicten:
Een bestandsconflict treedt op als er twee of meer ontwikkelaars dezelfde regel in één bestand hebben aangepast.
Een mapstructuur conflict treedt op als een ontwikkelaar een bestand of map verplaatst, hernoemd of verwijderd heeft, welke ook door een andere ontwikkelaar is verplaatst, hernoemd, verwijderd of gewijzigd is.
A file conflict occurs when two or more developers have changed the same few lines of a file. As Subversion knows nothing of your project, it leaves resolving the conflicts to the developers. The conflicting area in a text file is marked like this:
<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
Also, for every conflicted file Subversion places three additional files in your directory:
Dit is het bestand zoals het aanwezig was in je werkkopie, voordat je je werkkopie ging verversen. Oftewel de versie zonder conflictmarkeringen. Dit bestand bevat jouw laatste wijzigingen en niets anders.
Dit de BASE revisie van het is bestand voordat je je werkkopie ging verversen. Oftewel het bestand die je opgehaald hebt voordat je jouw laatste wijzigingen er in ging zetten.
Dit is het bestand die zojuist door je Subversion applicatie is ontvangen van de server toen je jouw werkkopie ging verversen. Dit bestand komt overeen met de HEAD revisie in het archief.
You can either launch an external merge tool / conflict editor with → or you can use any text editor to resolve the conflict manually. You should decide what the code should look like, do the necessary changes and save the file. Using a merge tool such as TortoiseMerge or one of the other popular tools is generally the easier option as they generally present the files involved in a 3-pane view and you don't have to worry about the conflict markers. If you do use a text editor then you should search for lines starting with the string <<<<<<<.
Daarna moet je het commando → kiezen en je wijzigingen vastleggen in het archief. Merk op dat het Opgelost commando het conflict zelf niet oplost. Het zorgt er alleen voor dat de bestanden filename.ext.mine en filename.ext.r* worden verwijderd, zodat je je wijzigingen kunt vastleggen.
Subversion zal niet proberen om conflicten met binaire bestanden zelf op te lossen. Het lokale bestand blijft ongewijzigd (precies zoals je het als laatste had opgeslagen) en je krijgt filename.ext.r* bestanden ernaast. Als je je eigen wijzigingen wilt laten vervallen en de versie in het archief wilt behouden, gebruik dan het Terugzetten commando. Als je je eigen versie wilt gebruiken en de versie in het archief wilt overschrijven, gebruik dan het Opgelost commando en leg vervolgens je wijzigingen vast.
Het is mogelijk om het Opgelost commando op meerdere bestanden toe te passen. Klik met rechts op de bovenliggende map en selecteer → . Er wordt dan een venster geopend met alle conflicterende bestanden in die map. Je kunt dan selecteren welke bestanden gemarkeerd moeten worden als Opgelost.
Een bestandsconflict treedt op als er twee of meer ontwikkelaars dezelfde regel in één bestand hebben aangepast. Zo'n conflict kan enkel maar opgelost worden door de ontwikkelaars.
If one of the changes must override the other then choose the option to Resolve using local property or Resolve using remote property. If the changes must be merged then select Manually edit property, sort out what the property value should be and mark as resolved.
Een conflict in mapstructuur ontstaat als een ontwikkelaar bestanden of mappen verplaatst, hernoemd of verwijderd heeft, die een andere ontwikkelaar toevallig ook verplaatst, hernoemd, verwijderd of gewijzigd heeft. Er zijn nog veel meer situaties die tot een mapstructuur conflict kunnen leiden en elke situatie heeft weer een andere oplossing nodig.
Als een bestand lokaal uit Subversion verwijderd is, dan wordt deze ook van het lokale bestandssysteem verwijderd. Dat houdt in dat er geen overlappend pictogram weergegeven kan worden als dit bestand onderdeel is van een mapstructuurconflict en je er dus ook niet met rechts op kunt klikken om het probleem op te lossen. Gebruik dan het Kijk of er updates zijn venster om de Conflicten oplossen optie te kunnen benaderen.
TortoiseSVN kan helpen om de beste plaatst voor het samenvoegen van wijzigingen te vinden, maar voor het oplossen van conflicten is er toch meer handwerk nodig. Onthoudt dat na een verversing de BASE altijd de revisie van bestanden uit het archief bevat van het moment van verversen. Als je een wijziging terugzet nadat je ververst hebt, dan kom je terug op de stand van het archief, niet naar de stand die je toen je begon met het wijzigen.
Ontwikkelaar A wijzigt Foo.c en verstuurt deze naar de repository.
Ontwikkelaar B heeft tegelijkertijd Foo.c naar Bar.c verplaatst in zijn werkkopie of heeft Foo.c of de bovenliggende map verwijderd.
Een verversing van de werkkopie van ontwikkelaar B resulteert in een mapstructuur conflict:
Foo.c is verwijderd uit de werkkopie, maar deze is gemarkeerd als een mapstructuur conflict.
Als het conflict veroorzaakt is door een hernoeming in plaats van verwijdering, dan zal Bar.c gemarkeerd worden als toegevoegd, maar deze zal dan niet de wijzigingen van ontwikkelaar A bevatten.
Ontwikkelaar B moet nu kiezen of hij de wijzigingen van ontwikkelaar A wil behouden. Als het om een naamswijziging gaat, dan kan hij de wijzigingen van Foo.c samenvoegen in het naar Bar.c hernoemde bestand. Bij eenvoudige bestands- of mapverwijderingen kan hij er voor kiezen om het object met de wijzigingen van ontwikkelaar A te behouden en de verwijdering te negeren. Of, door middel van het als Opgelost markeren van de conflicten zonder iets gewijzigd te hebben, worden de wijzigingen van ontwikkelaar A volledig genegeerd.
The conflict edit dialog offers to merge changes if it can find the original file of the renamed Bar.c. If there are multiple files that are possible move sources, then a button for each of these files is shown which allow you to chose the correct file.
Ontwikkelaar A hernoemt Foo.c naar Bar.c en legt de wijziging vast in het archief.
Ontwikkelaar B wijzigt Foo.c in zijn werkkopie.
Of bij een verplaatsing van een map ...
Ontwikkelaar A hernoemt hoofdmap FooFolder in BarFolder en legt de wijziging vast in het archief.
Ontwikkelaar B wijzigt Foo.c in zijn werkkopie.
Een verversing van de werkkopie van ontwikkelaar B leidt tot een mapstructuur conflict. Een eenvoudig bestandsconflict:
Bar.c wordt toegevoegd aan de werkkopie als een normaal bestand.
Foo.c wordt als toegevoegd (inclusief geschiedenis) gemarkeerd en heeft een mapstructuur conflict.
Een mapstructuur conflict:
BarFolder wordt aan de werkkopie toegevoegd als een normale map.
FooFolder wordt gemarkeerd als toegevoegd (inclusief geschiedenis) en heeft een mapstructuurconflict.
Foo.c wordt gemarkeerd als gewijzigd.
Ontwikkelaar B moet nu de keuze maken of deze meegaat met de herindeling van ontwikkelaar A. Als ontwikkelaar B daarin meegaat, kan hij zijn wijzigingen in het nieuwe bestand samenvoegen. Zo niet, dan kan ontwikkelaar B de wijzigingen van A terugdraaien en zijn eigen lokale versie behouden.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog. Then use the button which shows the correct source file to resolve the conflict.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog helps to track down what was moved.
Ontwikkelaar A hernoemt Foo.c naar Bar.c en legt de wijziging vast in het archief.
Ontwikkelaar B hernoemt Foo.c naar Bix.c
Een verversing van de werkkopie van ontwikkelaar B resulteert in een mapstructuur conflict:
Bix.c wordt gemarkeerd als toegevoegd inclusief geschiedenis.
Bar.c is toegevoegd aan de werkkopie met 'normale' status.
Foo.c wordt gemarkeerd als verwijderd en leidt tot een mapstructuur conflict.
Om dit conflict op te lossen, moet ontwikkelaar B uitzoeken welke bestandsnaam de conflicterend Foo.c heeft gekregen in het archief. Het log venster kan hiervoor gebruikt worden.
Ontwikkelaar B moet dan bepalen welke bestandsnaam van Foo.c behouden moet worden, degene van ontwikkelaar A of de zelf gekozen nieuwe bestandsnaam.
Wanneer ontwikkelaar B het conflict handmatig heeft opgelost, dan moet het conflict als opgelost worden gemarkeerd in het conflict bewerkingsvenster.
Ontwikkelaar A werkt in de basislijn en wijzigt Foo.c en legt de wijzigingen vast in het archief.
Ontwikkelaar B werkt aan een branch en hernoemd Foo.c in Bar.c en legt zijn wijzigingen vast in het archief.
Het samenvoegen van de wijzigingen van A op de basislijn naar de tak-werkkopie van ontwikkelaar B leidt tot een mapstructuur conflict:
Bar.c bevindt zich al in de werkkopie met status 'normaal'.
Foo.c wordt gemarkeerd als missend met een mapstructuur conflict.
Ontwikkelaar B moet het bestand als opgelost markeren in het conflict bewerkingsvenster, om ervoor te zorgen dat het bestand van de conflict lijst wordt gehaald. Vervolgens moet besloten worden of het missende bestand Foo.c vanuit het archief naar de werkkopie gekopieerd moet worden, of dat de wijzigingen van ontwikkelaar A in Foo.c samengevoegd moeten worden in Bar.c, of de wijzigingen te negeren door het conflict als opgelost te markeren zonder iets gewijzigd te hebben.
Merk op dat als je het missende bestand eerst uit het archief kopieert en het dan als opgelost markeert, dan je kopie meteen weer verwijderd wordt. Je moet eerst het conflict oplossen en daarna pas kopiëren.
Ontwikkelaar A werkt aan de basislijn en verplaatst <filename>Foo.c</filename> naar <filename>Bar.c</filename> en legt de wijziging vast in het archief.
Ontwikkelaar B werkt aan een vertakking (branch), wijzigt Foo.c en legt de wijziging vast in het archief.
Ontwikkelaar A werkt aan de basislijn en hernoemt de bovenliggende map FooFolder in BarFolder en legt de wijziging vast in het archief.
Ontwikkelaar B werkt aan de vertakking (branch) en wijzigt Foo.c in de werkkopie.
Het samenvoegen van de wijzigingen van A op de basislijn naar de tak-werkkopie van ontwikkelaar B leidt tot een mapstructuur conflict:
Bar.c is gemarkeerd als toegevoegd.
Foo.c is gemarkeerd als gewijzigd en met een mapstructuur conflict.
Ontwikkelaar B moet nu de keuze maken of deze meegaat met de herindeling van ontwikkelaar A. Als ontwikkelaar B daarin meegaat, kan hij zijn wijzigingen in het nieuwe bestand samenvoegen. Zo niet, dan kan ontwikkelaar B de wijzigingen van A terugdraaien en zijn eigen lokale versie behouden.
To merge her local changes with the reshuffle, Developer B must first find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source. The conflict editor only shows the log for the working copy as it does not know which path was used in the merge, so you will have to find that yourself. The changes must then be merged by hand as there is currently no way to automate or even simplify this process. Once the changes have been ported across, the conflicted path is redundant and can be deleted.
If Developer B decides that A's changes were wrong then she must choose the Mark as resolved button in the conflict editor dialog. This marks the conflicted file/folder as resolved, but Developer A's changes need to be removed by hand. Again the log dialog for the merge source helps to track down what was moved.
Ontwikkelaar A werkt aan de basislijn en verplaatst <filename>Foo.c</filename> naar <filename>Bar.c</filename> en legt de wijziging vast in het archief.
Developer B working on a branch moves Foo.c to Bix.c and commits it to the repository.
Het samenvoegen van de wijzigingen van A op de basislijn naar de tak-werkkopie van ontwikkelaar B leidt tot een mapstructuur conflict:
Bix.c is gemarkeerd met de normale (ongewijzigde) status.
Bar.c is gemarkeerd als toegevoegd inclusief geschiedenis.
Foo.c is gemarkeerd als missend en heeft een mapstructuur conflict.
To resolve this conflict, Developer B has to find out to what filename the conflicted file Foo.c was renamed/moved in the repository. This can be done by using the log dialog for the merge source.
Ontwikkelaar B moet dan bepalen welke bestandsnaam van Foo.c behouden moet worden, degene van ontwikkelaar A of de zelf gekozen nieuwe bestandsnaam.
Wanneer ontwikkelaar B het conflict handmatig heeft opgelost, dan moet het conflict als opgelost worden gemarkeerd in het conflict bewerkingsvenster.
Er zijn nog enkele andere situaties welke worden aangeduid als mapstructuur conflicten, dit komt doordat bij de conflicten mappen in plaats van bestanden betrokken zijn. Als je bijvoorbeeld een map met dezelfde naam in de basislijn en tak toevoegd en deze vervolgens probeert samen te voegen, dan zal er een mapstructuur conflict ontstaan. Als je de map van het samenvoeg doel wilt gebruiken, markeer het conflict dan als opgelost. Als je de map uit de samenvoeg bron wilt gebruiken, dan moet je de map in de doel structuur er met SVN Verwijderen en vervolgens de samenvoeging opnieuw starten. Als je een ingewikkeldere oplossing wilt hebben, dan zul je dat handmatig moeten doen.