Home

Hello. My name is Noemi Millman, and Triopter is my web development agency. We handcraft beautiful, dynamic websites.

See what I can do for you.

Noemi Millman: Triopter: Resolving "local delete, incoming delete upon update" Subversion Tree Conflicts

Resolving “local delete, incoming delete upon update” Subversion Tree Conflicts

NOTE 1: Before doing this, try using the svn resolve command.

NOTE 2: I’ve noticed a lot of traffic to this page for “local edit incoming delete on update” errors, which are not what this article is about (the solution below may or may not work for that — I have no idea). This article is about “local delete, incoming delete on update” errors. Always back up your work before you muck around with something like this, but that goes doubly if you’re going to try to use these instructions for the “local edit” error.

For reason I’m still trying to untangle, I encountered some really terrible conflicts this afternoon with an SVN checkin that didn’t complete properly, leaving me with a few locked directories that wouldn’t respond to “svn cleanup”.

Using these instructions, I was able to get the directories sorted out:

  1. Move offending directories out of working copy and to a safe place (e.g. desktop)
  2. Run svn cleanup
  3. Run svn up

This actually restored the messed-up directories. Some files were reverted and some deleted files restored; once the entire working copy is cleaned up, you can use the backup copies of the directories to copy back in your changes.

But before I could do that, I was left with a half-dozen individual file conflicts with the following messages:


$ svn st
?   C some_file.php
    > local delete, incoming delete upon update
?   C some_other_file.php
    > local delete, incoming delete upon update
... etc.

Thankfully, these were files that I did want to delete, so even without instructions I wasn’t afraid to trial-and-error my way to the following fix:


$ touch some_file.php some_other_file.php
$ svn revert some_file.php some_other_file.php

Once you’ve created the files, SVN can revert them, which leaves them in unversioned status:


$ svn st
?    some_file.php
?    some_other_file.php

And then you can just delete them from the command line or whatever file manager you use.

*Phew*

Once that was done I redid some deletions that had been overwritten by the update that cleaned up the directories, and all was right in the world.

Usual disclaimers, YMMV, etc.

  1. COMMENT: by Jeff Z., March 12th, 2010

    Thanks for posting this. You saved me a bunch of time today!

  2. COMMENT: by Mike Stoddart, April 12th, 2010

    Thanks! This helped me too!

  3. COMMENT: by Jo, April 14th, 2010

    Thanks mate

  4. COMMENT: by gjigandi, May 30th, 2010

    Thanks a lot!!!

  5. COMMENT: by Sri, June 30th, 2010

    Thanks so much for your post!! I was having problems merging my branch + trunk after 2 months of code changes. Works great now.

  6. COMMENT: by Chris, July 8th, 2010

    Thanks, this was helpful.

  7. COMMENT: by Dieter_be, August 13th, 2010

    Thanks!
    I had a “local edit, incoming delete upon update” which I could not resolve, and your instructions worked fine.
    Note that you don’t need to touch + revert + rm
    I just did an svn revert, which ironically, did not put the files back in place, but at least svn stopped complaining. (and still svn revert + rm would work as well, touching doesn’t seem to be needed)

  8. COMMENT: by Noemi Millman, August 13th, 2010

    Thanks, Dieter — that will be very helpful for some of the people who land here.

    I assume that a touch was not needed in your case because the files already existed in the local tree; whereas with the local delete / incoming delete version the files aren’t present locally, and for some reason SVN refuses to revert the missing files.

  9. COMMENT: by Ananth, February 16th, 2011

    Thanks mate. You saved my time.

  10. COMMENT: by Bruno, February 24th, 2011

    Thanks from Brazil. Saved my time (and my head).

  11. COMMENT: by Matthew, February 26th, 2011

    Thanks, so simple!

  12. COMMENT: by Renaud, March 22nd, 2011

    thanks a lot!

  13. COMMENT: by Tim, March 23rd, 2011

    Thanks :) worked for me on this error:
    “local delete, incoming delete upon merge”

  14. COMMENT: by Brian, March 30th, 2011

    Thanks! This works for directories as well as files. mkdir, revert, then rmdir. Yay!

  15. COMMENT: by Gustavo Bellino, May 11th, 2011

    Hello, thank you! I had the same problem but instead of being a file it was a folder, I did almost the same, I put
    svn revert name_of_the_folder (even if the folder does not exists)
    then
    svn cleanup
    and then wola! problem solved. Thank you.

  16. COMMENT: by Sylvain Bolay, May 17th, 2011

    Thanks a lot Noemi for this great help!

  17. COMMENT: by fatINbraIN, July 15th, 2011

    thx for solution.

  18. COMMENT: by Roy, August 24th, 2011

    Life saver. Thank you so much!

  19. COMMENT: by Henry, January 13th, 2012

    easy and smart way, thanks!

  20. COMMENT: by Christopher, April 13th, 2012

    THANKS!! This worked nicely.

  21. COMMENT: by olga, July 10th, 2012

    No need to ‘touch’ the files you meant to delete. svn revert will work on them right away and save you the extra steps.

  22. COMMENT: by Noemi Millman, July 11th, 2012

    olga, that may be the case for the “local edit” variant, but for the “local delete” problem, SVN won’t revert because it can’t find the files in the working copy. (Unless that’s changed in newer versions of SVN.)

    “touch” creates dummy files that SVN can work with.

  23. COMMENT: by shreyas kulkarni, July 19th, 2012

    hey thanks! that was spot on. man, svn is obtuse sometimes!

  24. COMMENT: by Rakesh, December 25th, 2012

    You are a life saver.. Thanks! :)

  25. COMMENT: by Eduardo, April 25th, 2013

    Thanks for that, helped me!

  26. COMMENT: by Barney, March 26th, 2014

    I’ve come from the future to say thanks. Thanks a million. J’ai bien tripot√© avec SVN, mais c’√©tait question de *comment* tripoter ;)

Post a Comment

Your email is never published nor shared. Required fields are marked *

Comments may be held for moderation to prevent spam: your comment may not appear immediately.