ConflictResolution

From Daya Bay

Jump to: navigation, search
This page was derived from NTU|env|wiki:ConflictResolution (http://dayabay.phys.ntu.edu.tw/tracs/env/wiki/ConflictResolution)


Conflict Resolution

Covered in depth in the SVN book :


Avoiding Conflicts

Adopting a modular development style has the benefits :

  • minimising conflicts with other developers
  • promoting reusability of the code, reducing duplication and hence reducing bugs
  • clarity as to who is responsible for the code


Conflicts will still occur, but they tend to be simple to fix if a clean modular approach is used. What does it mean to use a modular coding style ? On adding new functionality :

  • prefer to add a new class rather than adding to an existing one
  • if a new class would be inappropriate, then add a new method or function
  • keep classes short and focussed on a single task
  • avoid duplication of code


Look for Conflicts

On doing merge or update operations, always look carefully at the status codes reported :

U updated no local changes, just updated : so no worries
G merged cleanly merged , probably no worries
C conflict overlapping changes that need to be resolved before can commit
svn merge --dry-run -r 21:HEAD http://dayabay.phys.ntu.edu.tw/repos/dyw/branches/blyth-optical/G4dyb/src/dywAnalysisManager.cc G4dyb/src/dywAnalysisManager.cc 
C    G4dyb/src/dywAnalysisManager.cc

In the conflict case

  • conflict markers are added within the file, marking regions of overlapping changes
  • extra non-versioned files with messy endings will be added to the working copy


filename.mine locally modified version
filename.rOLDREV version as you checked it out should be the common ancestor
filename.rNEWREV HEAD version the version with other peoples modifications


Fixing conflicts

Steps required :

  • Compare your version with the common ancestor version to remind you of all the changes you made
  • Compare the trunk version with the common ancestor to understand what the other developers have been doing
  • Compare versions with each other to see where the conflicts are happening
  • Manually piece the files together so as not to annoy your fellow developers by dropping bits of their work while retaining your modifications

This task is made easier by tools like :

Linux vi with multiple buffers , invoke with vimdiff
Mac OS X FileMerge.app and opendiff commandline frontend tool specialized for precisely this task

Mac OS X specific details at NTU|env|wiki:ConflictResolutionOSX

After fixing, clean up the mess of non-versioned files created by the merge/update command with :

svn resolved filename 
Personal tools