A Comprehensive Guide to Resolving "local edit, incoming delete upon update" Tree Conflicts in SVN

Mechanism of SVN Tree Conflicts

In Subversion (SVN), a tree conflict occurs when there are structural changes to files or directories, rather than just content modifications. The "local edit, incoming delete upon update" scenario arises from a timeline misalignment in version control. For instance, Developer A edits a file (e.g., auto-complete.elc) in their local working copy, while Developer B deletes the same file in the remote repository and commits the change. When Developer A runs svn update, SVN detects uncommitted local edits but faces an incoming update that requires deletion, triggering a tree conflict.

SVN reports conflicts via status flags: in svn status output, !    C indicates a missing file with a conflict, and >   local edit, incoming delete upon update specifies the conflict type. Here, "local edit" refers to Developer A's uncommitted changes, and "incoming delete" means Developer B's committed deletion. This conflict cannot be resolved by simple merging, as it involves structural changes rather than content differences.

Step-by-Step Resolution Guide

Based on best practices, resolving such conflicts requires simulating the state transitions expected by SVN. The following steps use file conflicts as an example but apply equally to directory conflicts (with command adjustments).

First, confirm the conflict state. Run svn status ., with output possibly showing:

!  +  C foo
      >   local edit, incoming delete upon update
!  +  C bar
      >   local edit, incoming delete upon update

Here, foo and bar represent conflicting files, ! denotes missing files, + indicates history, and C marks the conflict.

Step 1: Recreate the missing conflict files. Since SVN detects missing files but the conflict is unresolved, restore their existence first. Use the touch command (or mkdir for directories):

$ touch foo bar

After this, svn status output changes to:

A  +  C foo
      >   local edit, incoming delete upon update
A  +  C bar
      >   local edit, incoming delete upon update

Now, SVN marks the files as scheduled for addition (A), but the conflict persists.

Step 2: Use svn revert to restore files to the deleted state expected by SVN. This command undoes all uncommitted local changes, including additions and deletions:

$ svn revert foo bar

After execution, conflict markers disappear, and files become unversioned:

?       foo
?       bar

Step 3: Safely delete these files. As they are no longer under SVN control, they can be removed directly:

$ rm foo bar

Finally, svn status shows no conflicts, and the working copy is clean.

Alternative Approaches and Extended Discussion

Beyond this method, SVN offers the svn resolve command as a direct conflict resolution tool. For example, run:

svn resolve --accept=working foo

This command accepts the local working copy state as the resolution. However, in "local edit, incoming delete upon update" scenarios, if local files are missing, svn resolve might not apply directly, as it requires files to exist for conflict evaluation. Thus, recreating files is often necessary in such cases.

Another common variant is "local delete, incoming delete upon update", with status output like:

!     C foo
      >   local delete, incoming delete upon update

Here, both local and remote require deletion, but SVN still reports a conflict. The resolution is similar: recreate files (using touch or mkdir), then execute svn revert, and finally delete the files.

For directory conflicts, the logic is the same, but note command differences. For instance, recreate directories with mkdir and delete them with rm -r. Always backup important data before operations, as revert and deletion are irreversible.

Prevention and Best Practices

To avoid such conflicts, developers should follow SVN workflow best practices. First, always run svn update before starting edits to ensure the working copy is synced with the latest repository. Second, commit small changes frequently to reduce conflict windows. Third, use svn status regularly to check for potential issues early. Lastly, establish clear communication within teams, especially for structural changes like file deletions or renames.

Understanding SVN's conflict resolution mechanisms not only aids in quick fixes but also enhances version control efficiency. By simulating state transitions, developers can gain deeper insights into SVN's internal workings, enabling confident handling of complex scenarios.