[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 20 Feb 2011 13:12:36 -0500

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.