Working on a large project with others can be difficult to coordinate. When each user is working on a set of files for some task, sooner or later users will try to commit the same file in two different versions. This is called a conflict.
This guide will demonstrate the basic steps you can take to resolve a conflict once it has happened. We deal with three solution strategies:
- Theirs - choosing to accept all incoming changes and discarding all your own changes to a conflicting file.
- Mine - the opposite of theirs, discarding all changes done by other users to a file since you last updated it from the server.
- Manual/merge - the most time consuming, but by far also most effective strategy. You must manually go through the different versions of conflicting files and assemble a new file from the changes to commit. This is easier than it sounds, although it does require some work.
Conflicts are detected during an update procedure. Using RabbitVCS, a window such as the one below is shown. Note that it offers the three solutions described. Clicking either Accept Mine orAccept Theirs will tell RabbitVCS to discard the incoming changes or yours, respectively. If you tick the checkbox, RabbitVCS will note that the file in question should no longer be considered in conflict.
Finally, click Merge Manually to continue with the update procedure, marking the file as conflicted.
For each conflicting file, RabbitVCS will create three files in the same folder as depicted below. In the example, the file main.cpp has been changed locally, and an update was attempted before committing the changed file. However, someone else has already modified the file, causing the conflict.
- main.cpp.mine is the local file with uncommitted changes.
- main.cpp.r8 is the new version with conflicting changes
- main.cpp.r7 is the original version before the conflicting version.
- main.cpp is now a file with attempted merges by Subversion
If you open the primary file (with automatic merges) in a text editor, you will see an amalgam of all the versions with annotation. For every conflicting area in the file, you will first see your own version of those changes (starting right after <<<<<<< .mine going to =======), followed by the conflicting version's data (going to >>>>>>> .rX).
When editing the conflicting file directly without resorting to theirs or mine resolutions, it is the intention that you read the differences for each conflicting area individually, determining what a unified solution should look like. Replace the area with your unified version until all internal conflicts have been resolved.
Once you have completed resolving the conflict within a file, save your changes and right-click on the file in Nautilus. Click on RabbitVCS SVN and finally Mark As Resolved.
You are asked to confirm the resolution. Simply confirm by clicking OK.