svn's merge command has three twisty little syntaxes, none
very DWIM-ish. For merging one file, apparently it is helpful
to specify that file itself. This patch does that.
The bug that this fixes is hard to demonstrate without
generating a lot of noise, but you can get the idea by
finding a file that was committed in a subdirectory and
merging a change with it.
[apu]$ emacs one/test.mdwn
[apu]$ svn add one/test.mdwn
A one/test.mdwn
[apu]$ svn commit -m "Another test case for merging."
Adding one/test.mdwn
Transmitting file data .
Committed revision 42.
[apu]$ emacs one/test.mdwn
[apu]$ svn commit -m "Change."
Sending one/test.mdwn
Transmitting file data .
Committed revision 43.
svn merge -r38:39 ~/ikidevwc/patches/merge.patch
[apu]$ svn merge -r42:43 one/test.mdwn
svn: Cannot replace a directory from within
[apu]$ svn merge -r42:43 ~/ikidevwc/one/test.mdwn
svn: Cannot replace a directory from within`
CGI.pm does a command much like the last one. However:
[apu]$ svn merge -r43:42 ~/ikidevwc/one/test.mdwn
svn: Cannot replace a directory from within
[apu]$ svn merge -r43:42 ~/ikidevwc/one/test.mdwn ~/ikidevwc/one/test.mdwn
U /home/glasserc/ikidevwc/one/test.mdwn
In other words, merging works only when you specify
the file, or, alternately:
[apu]$ cd one
[apu]$ svn merge -r42:43 ~/ikidevwc/one/test.mdwn
G test.mdwn
... if you're in the same directory as the file. Note that if
a file called "test.mdwn" happens to be where you are, it'll get
changed! I think this is what is meant in svn help merge
when
it says:
If WCPATH is omitted, a default value of '.' is assumed, unless
the sources have identical basenames that match a file within '.':
in which case, the differences will be applied to that file.
So, to conclude: when merging two revisions of a file, either specify
the file, or be in the same directory as a file with the same name.
This patch makes the former always happen, whereas previously the
second would sometimes not happen. It also obviates the call to chdir.
Source: this message on the svn-user list.
--Ethan