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 <dtrebbien_at_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.
Received on 2011-02-20 19:13:53 CET