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.
Een bestandsconflict treedt op als twee of meer ontwikkelaars dezelfde regels in een bestand hebben gewijzigd. Omdat Subversion niets van de projecten weer, laat het het oplossen van conflicten over aan de gebruikers. Als er een conflict gemeld wordt, dan moet je het bestand in kwestie openen en de regels zoeken die beginnen met <<<<<<<. Het conflicterende gedeelte wordt als volgt gemarkeerd:
<<<<<<< filename your changes ======= code merged from repository >>>>>>> revision
Daarnaast plaatst Subversion drie additionele bestanden in je map:
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.
Je kunt of een extern samenvoeg/conflict bewerkingsprogramma openen met → of je kunt elke tekstverwerker gebruiken om handmatig de conflicten op te lossen. Je moet beslissen hoe de code er uit zou moeten zien, de noodzakelijke wijzigingen doorvoeren en het bestand opslaan.
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 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 legt deze vast in het archief
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.
Het conflicten bewerkingsvenster beidt de mogelijkheid om wijzigingen samen te voegen, als het originele bestand van de hernoemde Bar.c aangewezen kan worden. Afhankelijk van waar de verversing was aangeroepen, is het misschien niet mogelijk om het bronbestand te vinden.
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.
Om de eigen wijzigingen in de herindeling te verwerken, moet ontwikkelaar B uitvinden welke naam Foo.c heeft gekregen in het archief. Dit kan met het log venster. De wijzigingen moeten vervolgens met de hand verwerkt worden, omdat er nu nog geen mogelijkheid is dit te automatiseren of te vereenvoudigen. Als de wijzigingen doorgevoerd zijn, is het conflicterende pad overbodig en kan dan verwijderd worden. Gebruik hiervoor de Verwijderen knop in de conflict bewerkingsvenster om het conflict als opgelost ge markeren.
Als ontwikkelaar B tot de conclusie komt dat de wijzigingen van A verkeerd zijn, dan moet dat aangegeven worden met de Behouden knop in het conflict bewerkingsvenster. Hiermee wordt het conflicterende bestand of de map gemarkeerd als opgelost. De wijzigingen van ontwikkelaar A moeten wel nog met de hand verwijderd worden. Ook hier helpt het log venster met te bepalen wat er gewijzigd/hernoemd is.
Ontwikkelaar A hernoemt Foo.c in Bar.c en legt dit vast in het archief.
Ontwikkelaar B hernoemt Foo.c in 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 hernoemt Foo.c in Bar.c 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.
Er is een vergelijkbare situatie voor verplaatste mappen, maar dit wordt nog niet gedetecteerd in Subversion 1.6 ...
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.
Om de eigen wijzigingen in de herindeling te verwerken, moet ontwikkelaar B uitvinden welke naam Foo.c heeft gekregen in het archief. Dit kan met het log venster van het samen te voegen bronbestand. De conflict verwerker toont alleen het log van de werkkopie, omdat niet bekend is welk pad gebruikt is bij het samenvoegen. Dit moet je zelf handmatig uitzoeken. De wijzigingen moeten vervolgens met de hand verwerkt worden, omdat er nu nog geen mogelijkheid is dit te automatiseren of te vereenvoudigen. Als de wijzigingen doorgevoerd zijn, is het conflicterende pad overbodig en kan dan verwijderd worden. Gebruik hiervoor de Verwijderen knop in de conflict bewerkingsvenster om het conflict als opgelost ge markeren.
Als ontwikkelaar B tot de conclusie komt dat de wijzigingen van A verkeerd zijn, dan moet dat aangegeven worden met de Behouden knop in het conflict bewerkingsvenster. Hiermee wordt het conflicterende bestand of de map gemarkeerd als opgelost. De wijzigingen van ontwikkelaar A moeten wel nog met de hand verwijderd worden. Ook hier helpt het log venster met te bepalen wat er gewijzigd/hernoemd is.
Ontwikkelaar A werkt aan de basislijn en hernoemt Foo.c in Bar.c en legt de wijziging vast in het archief.
Ontwikkelaar B werkt aan een vertakking (branch) en hernoemt Foo.c naar Bix.c en legt de wijziging 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:
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.
Om dit conflict op te lossen, moet ontwikkelaar B uitzoeken welke bestandsnaam de conflicterend Foo.c heeft gekregen in het archief. Het log venster van het samen te voegen bronbestand kan hiervoor gebruikt worden. Het conflict verwerker toont alleen het log van de werkkopie, omdat niet bekend is welk pad gebruikt is bij het samenvoegen. Je moet dat pad zelf handmatig opzoeken.
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.