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_at_N-1 config/
$ svn commit -m "merge branch A, and restore config/bar.java"
Received on 2011-05-25 12:06:29 CEST