On Sun, Feb 20, 2011 at 09:39:01AM -0800, Danny Trebbien 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.
The file isn't versioned yet. So it cannot be considered part of the
'mine' changeset. You should add the file so that Subversion knows
it is supposed to consider it.
However, if you add the file you will get a tree conflict when you update.
And interactive conflict resolution doesn't handle tree conflicts yet.
So the various --accept= options don't work for tree conflicts either.
Interactive conflict resolution for tree conflicts should of course be
added eventually but has been postponed until wc-ng is ready to handle
tree conflicts better.
The error message you're getting could be improved, of course.
It should probably say 'Skipped foo', because we're usually skipping
unversioned obstructions because we don't want to touch them in any way.
Does svn status report the newly added file as obstructed after the update?
I think it should.
Received on 2011-02-20 19:18:06 CET