Skip to main content

Resolving a text conflict

A text conflict can occur when two users make mutually contradicting parallel changes to the contents of the same file.

Regardless of the operation (a merge, update or switch) during which the conflict occurred, the effects of conflicts and the ways to resolve conflicts are essentially the same.

Example of a text conflict​

Let’s assume that the trunk directory contains a file sandwich.txt, originally with the following contents:

How to make a sandwich:

Top slice of bread
Tomato
Cheese
Bottom slice of bread

Changes on your feature branch​

Suppose that you create a new feature branch that you call edit_recipes from the trunk. On that edit_recipes branch, you edit the sandwich.txt, replacing Tomato with Pepper. You save and commit that change to the branch.

So the file sandwich.txt on the edit_recipes branch now contains the following:

How to make a sandwich:

Top slice of bread
Pepper
Cheese
Bottom slice of bread

Changes on the trunk​

Suppose that in the meantime, after you created that edit_recipes branch, your teammate edits the same file on the trunk, but edits it differently, replacing Tomato with Salami. That teammate commits their change to the trunk.

So the file sandwich.txt on the trunk now contains the following:

How to make a sandwich:

Top slice of bread
Salami
Cheese
Bottom slice of bread

Syncing the feature branch​

Now, if you perform a sync merge from the trunk into your working copy of edit_recipes, Subversion will inform you that there is a conflict:

Merge conflict discovered in file 'sandwich.txt'.
Select: (p) Postpone, (df) Show diff, (e) Edit file, (m) Merge,
        (s) Show all options:

This is a contradicting-change conflict. Your change and your teammate’s change overlap (affect the same line in the same file) and contradict each other. The version control system does not know whose change is preferable. And to resolve the conflict you need to make a decision, whose change (or maybe a combination of them, or neither of them) you want to keep in this document.

Postponing conflict resolution​

When a command results in a conflict, typically users choose to postpone conflict resolution, by entering p (for “postpone”) when prompted. This lets the current command (such as a merge or an update) finish.

After that, you can examine the conflicted files in the working copy one by one, and resolve these conflicts at a convenient pace. You will need to resolve the conflicts in the working copy before Subversion will allow you to commit your changes.

Resolving a text conflict​

Identifying the conflicted file​

If you have postponed conflict resolution, then after the operation (such as a merge or an update) completes, you can display the status of the working copy to see which files in the working copy currently have unresolved conflicts.

Suppose that you have the conflict described in the Example of a text conflict. Then the status of the working copy would show the following:

C:\Users\Alex\my_work_dir> svn status
 M      .
C       sandwich.txt
?       sandwich.txt.merge-left.rBEFORE
?       sandwich.txt.merge-right.rAFTER
?       sandwich.txt.working
Summary of conflicts:
  Text conflicts: 1

The letter C in the left-most column on the sandwich.txt line indicates that this item has a text conflict, i.e. conflicting changes in the contents of this file.

In TortoiseSVN, to see conflicted items, right-click in the File Explorer at the root of your working copy, and then select TortoiseSVN | Check for modifications.

Competing versions of the conflicted file​

In the conflicted file itself (e.g. sandwich.txt), Subversion will put conflict markers that indicate which lines are in conflict.

Subversion also places three extra unversioned files into the working copy, which have the same name as the conflicted file, but have different appended extensions. These temporary unversioned files represent the different competing versions of the conflicted file. Once you resolve the conflict in sandwich.txt, the Subversion client automatically deletes these auxiliary files.

Competing versions after a merge​

If a text conflict occurred during a merge, the competing versions of the conflicted file will have the following extensions:

  • .merge-left.rBEFORE is the version that does not contain any of the conflicting changes. That is, it does not contain the incoming changes from the source branch and it does not contain the conflicting changes from the target branch.
  • .merge-right.rAFTER is the version that contains the incoming changes (from the source branch).
  • .working is the version that your working copy contained before the merge. It contains the conflicting changes that were made on the target branch.

Competing versions after an update​

If a text conflict occurred during an update, the competing versions of the conflicted file will have the following extensions:

  • .rBEFORE is the version that does not contain any of the conflicting changes. It does not contain the incoming changes from the update and it does not contain your conflicting local uncommitted changes.
  • .rAFTER is the version received from the update.
  • .mine is the version with your local uncommitted edits that your working copy contained before the update.

Resolving interactively​

In modern Subversion (1.8 and later), you can run the svn resolve command on the conflicted file, to show all the available resolution options and choose one of them. You can enter s to see all the options.

For text conflicts in plain-text files (such as .txt, .md or source-code files), you can choose the i option that opens a built-in conflict editor, where you can choose which change to keep in each conflicted segment:

C:\Users\Alex\my_work_dir> svn resolve sandwich.txt
Merge conflict discovered in file 'sandwich.txt'.
Select: (p) Postpone, (df) Show diff, (e) Edit file, (m) Merge,
        (s) Show all options: i
Merging 'sandwich.txt'.
Conflicting section found during merge:
(1) their version (at line 4)          |(2) your version (at line 4)
---------------------------------------+---------------------------------------
Salami                                 |Pepper
---------------------------------------+---------------------------------------
Select: (1) use their version, (2) use your version,
        (12) their version first, then yours,
        (21) your version first, then theirs,
        (e1) edit their version and use the result,
        (e2) edit your version and use the result,
        (eb) edit both versions and use the result,
        (p) postpone this conflicting section leaving conflict markers,
        (a) abort file merge and return to main menu:

In TortoiseSVN, you can launch its conflict editor by right-clicking the conflicted file and choosing Edit Conflicts.

Suppose that for this conflicted segment you decide to enter option 2: to use your version of this conflicting line. Since this is the only conflicting line, Subversion will offer you to mark all the conflicts in the file as resolved. Once you mark the conflicts in this file as resolved, the Subversion client will automatically delete the auxiliary copies of the conflicted file. The contents of this file after resolving the conflict is:

How to make a sandwich:

Top slice of bread
Pepper
Cheese
Bottom slice of bread

That is, you chose to keep your version of that conflicted line.

This example of a text conflict contained just one conflicting segment. However, for files with multiple conflicting segments, the built-in conflict editor offers great flexibility, because for each segment (hunk) that is in conflict you will be able to choose a different resolution. For example, on one conflicting line you may choose to keep the incoming change (theirs) and on another conflicted line you may decide to keep your change.

While the approach above allows you to granularly resolve conflicts line-by-line, there are also less granular interactive options. For example, options mf (mine-full) or tf (theirs-full) allow you to keep either your version or the incoming version of the file, completely discarding the changes in the other version. Whereas the option mc ( mine-conflict) prefers your changes in this file on all conflicting lines, but applies the incoming teammate’s changes that do not conflict with yours.

In the TortoiseSVN GUI, to choose an automated option, right-click at the root of your working copy, select TortoiseSVN | Check for modifications, then right-click the conflicted file and select one of the automatic resolution options, such as Resolve conflict using mine, which is equivalent to the mf (mine-full) automated option.

Note that the Resolved option is used for manual conflict resolution described in the next section.

Resolving manually​

Alternatively, you may want to resolve the conflict manually by editing the sandwich.txt file. If you open the conflicted file sandwich.txt itself you will see that around the line that is in conflict there are conflict markers, and the different competing variants of this line are specified:

<<<<<<< .working
Pepper
||||||| .merge-left.r2
Tomato
=======
Salami
>>>>>>> .merge-right.r5

Edit sandwich.txt to a desired state in a text editor (such as Notepad) and remove the conflict markers from the text. Then, mark the conflict as manually resolved by accepting the file that you manually edited:

C:\Users\Alex\my_work_dir> svn resolve sandwich.txt --accept working

In the TortoiseSVN GUI, to mark the conflict as manually resolved, right-click at the root of your working copy, select TortoiseSVN | Check for modifications, then right-click the conflicted file and select Resolved.

Resolving a text conflict in a non-plain-text file​

Resolving interactively​

If a text conflict is in a non-plain-text binary file (e.g. in a .png image file), the built-in command-line resolver cannot resolve it granularly line-by-line. For such a conflicted file, the command-line resolver provides only two options: either keep the version in your working copy: mf (Mark as resolved) or fully replace the file with the incoming version: tf (Accept incoming).

Run the svn resolve command on the conflicted file:

C:\Users\Alex\my_work_dir> svn resolve screenshot.png

Select one of the suggested built-in resolution options.

Resolving with a third-party merge tool​

For more flexibility when comparing and merging conflicting changes in non-plain-text files, it is also possible to manually launch an external third-party merge tool and point it to the Competing versions of the conflicted file presented in the working copy.

In this case, just like in the manual resolution, you (or the external merge tool) should eventually replace the conflicted file in the working copy with a final desired variant of this file. And then you may need to mark the conflicts in this file as manually resolved, by accepting the file’s current final state in the working copy:

C:\Users\Alex\my_work_dir> svn resolve screenshot.png --accept working

For non-plain-text (binary) files, the command-line client currently cannot be configured to automatically use an external three-way differencing or merge tool.

However, when using TortoiseSVN, you can configure its Edit conflicts command to launch an external merge tool either for all conflicted files or only for specific file formats. For more details, see External Program Settings. Furthermore, for some file formats (such as for Microsoft Office documents), the Edit conflicts command in TortoiseSVN is by default configured to launch a suitable application on your computer (e.g. Microsoft Word) and use it as an external merge tool.