See
http://svn.haxx.se/dev/archive-2005-05/0562.shtml
for when this was first brought up.
'svn merge' will quite happily merge changes into schedule add files, I think
this is the correct thing to do. However the merge can produce a conflict and
such conflicts are not handled particularly well.
The first problem is that svn_wc_status_t can indicate either the schedule add
or the conflict, but not both. The code happens to choose the schedule add, but
that's probably an accident. This means that 'svn status' will show state 'A'
rather than 'C', although the left/right/working files show up as '?'. Commit
attempts will fail until the user realises that the conflict must be resolved.
It's not clear whether we should prefer status 'A' or 'C', although I think 'C'
is marginally better. I suppose the real solution is a new symbol, although
that probably involves an ABI change.
The next question is how 'svn revert' should handle such a file. Should it
attempt to revert the conflict or should it revert the scheduling? At present
it reverts the schedule add and ignores the conflict, in particular it leaves
the left/right/working files behind. If the file is an add with history then it
has a text base that could be used to revert the conflict, would this be the
correct thing to do? Should the left/right/working files be removed?
Bug
Major