That is an obstruction you have to use --force to allow unversioned obstructions.
Sent from my iPhone On Feb 20, 2011, at 12:39 PM, Danny Trebbien <dtrebb...@gmail.com> wrote: > 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.
