On Tue, May 24, 2011 at 07:35:49PM -0400, David Tombs wrote: > Thanks for the response. Unfortunately, I don't think my solution turned > out very well. I ended up with a corrupted working copy that thought > bar.java was there but the server disagreed whenever I did a > server-hitting command.
Replaced directories aren't really supported in 1.6.x. They sort of work in some situations but Subversion often does something wrong. I would be interested if this still happens in Subversion 1.7. Can you list the precise sequence of commands that lead to this situation, preferrably starting from an empty repository? Then I could try to reproduce the problem with 1.6.x and with trunk. If you have the time you could even try to reproduce the problem yourself on a working copy with binaries compiled from Subversion's trunk. Windows binaries of fairly recent trunk states are available here: https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows and here (in the TortoiseSVN flavour): http://nightlybuilds.tortoisesvn.net/latest/ For unix-like systems there are nightly source tarballs available at http://ci.apache.org/projects/subversion/nightlies/index.html which are ready to configure; make; make install provided you have all required dependencies installed. > I guess what I should have done instead was delete config and then > re-add bar.java instead of reverting it. Yes, something like this should work well: $ svn rm config $ svn commit -m "temporarily remove config from branch B (tree conflict)" ... Committed revision N. <-- remember this number N $ svn merge ... ^/branches/A ... ... A config ... $ svn cp ^/branches/B/config/bar.java@N-1 config/ $ svn commit -m "merge branch A, and restore config/bar.java"
