Conflicts

What is a conflict?

A conflict might occur when you combine two groups of changes that were made in parallel to each other. A conflict occurs if these two groups of changes overlap and contradict each other.

Conflicts never occur when users are simply making sequential changes on a branch, i.e. when you make changes on top of the current latest revision of a branch and are not receiving these changes via a merge.

In Subversion, a conflict may usually occur during a merge or an update, because these commands bring changes that have been made in parallel to your changes. A merge brings changes from another branch. Whereas an update brings changes from the same branch as your working copy, which have occurred in the repository since you last updated your working copy.

For example, suppose that you have committed some edits to a file on your feature branch (a parallel line of history). And suppose that since you created that feature branch, your teammate has committed different edits affecting the same lines in the same file on the trunk (the project’s main line of history). Now when you sync your feature branch with the trunk, a conflict will occur, because the incoming changes from the teammate contradict yours. See the Example of a text conflict where such a case is described in more detail.

In contrast to that, a merge or an update can cleanly combine changes made in parallel by different users when these changes do not overlap. For example, if your teammate and you edited different files or edited different parts of the same file in parallel, then a merge or an update can cleanly and automatically combine these changes without any conflict.

Even if you have not used branching before and have been committing directly to the trunk, you might have encountered conflicts when updating your working copy. Conflicts during a merge and during an update are essentially the same. The only significant difference between them is where the conflicting changes come from.

Where do the conflicting changes come from?

Depending on whether the conflict occurred during an update, a switch or a merge, the origin of the conflicting changes is different.

Update (or switch) conflict

A conflict during an update or a switch can occur only if your working copy has local uncommitted changes. This type of conflict means that the incoming changes (from the update or switch) overlap with the local uncommitted changes in your working copy.

Merge conflict

During a merge, a conflict can occur even when your working copy has no local uncommitted changes. And in fact the best practice is to merge into a working copy that has no local uncommitted changes.

Such a conflict can occur because each branch has its separate timeline of commit history, and changes made on the source and the target branch can contradict each other.

A merge conflict can be thought of as an overlap and contradiction between the incoming changes (from the source branch) and the independent branch-specific changes that have occurred on the target branch since the moment when the source branch and the target branch split.

Where can a conflict occur?

As already mentioned, a conflict might occur when you combine two groups of changes that were done in parallel to each other. Based on where these parallel changes were made, the following conflicts are possible:

• text conflict - is a conflict in the contents of a file. It occurs when two users have changed the same lines in the same plain text file. More broadly, it can also occur if two users have edited the same non-plain text file (e.g. a picture), for which a line-based merge is not possible. For information on handling such conflicts, see Resolving a text conflict.

• property conflict - is any conflict in a versioned property attached to a file or directory. It occurs when two users manually change the same metadata property (like svn:global-ignores) attached to the same file or directory. For information on handling such conflicts, see Resolving a property conflict.

• tree conflict - is a conflict at the level of versioned directory structure. It can occur when one user changes the hierarchy of versioned files or directories in a way that contradicts or overlaps with a change made by another user. For example, it can occur when one user edits a file that another user has deleted or moved. Or when two users move the same file to different locations. For information on handling such conflicts, see Resolving a tree conflict.

Contradicting-change versus tool-induced conflicts

To have a smooth workflow, it is useful to distinguish when a conflict is a natural consequence of collaboration and when it is caused by a mistake in using Subversion. For the purposes of this guide, let us call the former a “contradicting-change conflict” and the latter a “tool-induced conflict”.

What is a contradicting-change conflict?

Contradicting-change conflicts are conflicts where you are combining two overlapping and mutually-contradicting changes, and you need to choose which one of them you want to keep in the final result. Such as in the case described in the Example of a text conflict.

In any version control system, occasionally having contradicting-change conflicts is inevitable when multiple people collaborate.

Having such conflicts is completely normal. However, you should still strive to minimize or avoid them where possible, to prevent the need to resolve them during updates and merges. You can minimize such conflicts by how you organize and divide tasks in your team. See Planning changes in Best practices.

What is a tool-induced conflict?

Tool-induced conflicts are conflicts that arise when some Subversion operations have been misused.

For example, such a conflict can occur if you don’t use the correct way to create new branches (see Step 1: Create a new branch and the relevant best practices listed for it). Or it can occur if during a previous merge you reverted the automatic change in the merge tracking information (mergeinfo), but still committed other merged changes.

Such mistakes can result in conflicts when there is no real contradiction or overlap in the changes made on different branches. Tool-induced conflicts can and should be easily avoided all of the time by using the Subversion commands correctly, which includes following the relevant best practices.