ConflictResolution
Jump to navigation
Jump to 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