Bug? svn update --accept mine-full fails if an added file exists unversioned in the working copy

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.
Received on 2011-02-20 18:39:43 CET