Resolving SVN Tree Conflicts: Local Obstruction and Incoming Add When Files Are Added on Two Branches

Conflict Phenomenon and Nature Analysis

In Subversion (SVN) version 1.6.1 and above, when merging two branches where the same file (e.g., foo.txt) has been added and independently modified on both branches, the system reports a specific tree conflict: local obstruction, incoming add upon merge. A typical output is shown below:

      C foo.txt
  >   local obstruction, incoming add upon merge

Unlike regular text conflicts, tree conflicts do not generate auxiliary files such as .working, .merge-left, and .merge-right, as the conflict stems from structural differences rather than content variations. According to SVN's official tree conflict design documentation, this scenario is described as "bringing a file addition without history onto an existing versioned file," which is an expected type of tree conflict.

Theoretical Background and Solutions

This conflict is often referred to as "evil twins" in version control terminology, originating from ClearCase, where the same filename is created on two different branches, forming two independent histories. Theoretically, resolving such conflicts centers on manually merging the file contents from both branches. Since SVN cannot automatically handle these structural conflicts, users must rely on external diff tools (e.g., diff or Beyond Compare) to compare and integrate changes from both versions.

An ideal resolution strategy involves optimizing branch management: if still working on the source branch, it is advisable to remove the file from the source branch and then merge back from the target branch to the source, allowing the file to share the same history across both branches. However, in practical workflows where merge directions are fixed (e.g., only from branch B1 to B2), manual handling of these conflicts is required for each merge operation.

Practical Steps for Resolution

To address the local obstruction, incoming add upon merge conflict, follow these steps:

1. Use the svn status command to confirm the list of conflicting files.
2. For each conflicting file, employ an external diff tool to compare versions from both branches. For example, use svn diff combined with a graphical tool for visual differentiation.
3. Manually edit the file in the target branch to integrate changes from both branches. Ensure all necessary modifications are preserved to avoid data loss.
4. After resolving content conflicts, use the command svn resolve --accept working <file-path> to mark the local version as resolved. This command accepts the current state of the working copy and clears conflict markers.
5. Repeat these steps until all conflicting files are handled, then execute svn commit to complete the merge.

Note that while the svn resolve --accept working method is convenient, it may overwrite incoming changes; thus, it is recommended to use it after manual merging to ensure content integrity. For large-scale conflicts, batch processing of directories instead of individual files can improve efficiency.

Additional Notes and Best Practices

Beyond manual merging, preventing such conflicts is crucial. In team development, establish clear branch management guidelines to avoid adding files with the same name on different branches. If unavoidable, early communication and coordination of changes, or using branch refactoring techniques (e.g., renaming files), can reduce conflict risks. SVN's tree conflict mechanism, while adding complexity to merges, offers finer version control capabilities; understanding its principles enhances workflow stability.

From a technical perspective, HTML tags such as <br>, when described as text objects, must be properly escaped (e.g., written as <br>) to prevent parsing errors. This differs fundamentally from functional <br> tags used for line breaks, illustrating the separation of content and code.