For update, the '--force' switch means "If a local file obstructs an incoming add, then use that file (and flag the file as locally-'M'odified) instead of flagging a tree conflict". Have you tried it?
P.S. In Subversion 1.7, you can spell that '--accept mf' too :-) (using the shorthands from the interactive conflict resolution prompt) Danny Trebbien wrote on Sun, Feb 20, 2011 at 09:39:01 -0800: > I have a check out of Subversion trunk and the official Apache git > mirror of Subversion coexisting in the same directory (my working copy > is both a Subversion and git working copy). Because I want to use git > to hack on trunk, I normally update the working copy using git, and > then update the Subversion meta data later when I am ready to generate > a patch. > > In my current setup, Subversion thinks that my working copy is at > revision 1070224, but in actuality it is at 1072544. > > Previously I was able to update the Subversion meta data by executing > `svn update --accept mine-full -r ###`, where ### is whatever revision > that the git mirror is at. When I try it for my current working copy > (### is 1072544), I see an error: > > svn: Failed to add file 'notes/wc-ng/pristine-store': an > unversioned file of the same name already exists > > That particular file was added in revision 1071707, so it appears that > `--accept mine-full` does not apply when a file is added in a > revision. > > I think that this is a bug because I expect that Subversion will > accept mine (i.e. the current copy of notes/wc-ng/pristine-store in my > working copy, albeit "unversioned") to update to r1071707.