[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sun, 20 Feb 2011 20:11:47 +0200

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.
Received on 2011-02-20 19:17:08 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.