You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Danny Trebbien <dt...@gmail.com> on 2011/02/20 18:39:01 UTC
Bug? svn update --accept mine-full fails if an added file exists
unversioned in the working copy
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.
Re: Bug? svn update --accept mine-full fails if an added file exists unversioned in the working copy
Posted by Mark Phippard <ma...@gmail.com>.
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 <dt...@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.
Re: Bug? svn update --accept mine-full fails if an added file exists
unversioned in the working copy
Posted by Danny Trebbien <dt...@gmail.com>.
On Sun, Feb 20, 2011 at 10:11 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> 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)
Oh, okay. I will try that next time because I got around this problem
by `svn add`ing each file and re-trying the update until it finally
succeeded.
Re: Bug? svn update --accept mine-full fails if an added file
exists unversioned in the working copy
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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.
Re: Bug? svn update --accept mine-full fails if an added file exists
unversioned in the working copy
Posted by Danny Trebbien <dt...@gmail.com>.
On Sun, Feb 20, 2011 at 10:17 AM, Stefan Sperling <st...@elego.de> wrote:
> 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.
I got around this problem by `svn add`ing each file and re-trying the
update until it finally succeeded.
Afterward, `svn status` reports:
? add_test-3.patch
? .git
? source-prop-encoding-5.1.patch
? .gitattributes
? source-prop-encoding_log_message-5.1.txt
? .gitignore
M subversion/tests/libsvn_subr/subst_translate-test.c
M subversion/tests/cmdline/svnrdump_tests.py
M subversion/tests/cmdline/svnsync_tests.py
? subversion/tests/cmdline/svnsync_tests_data/copy-bad-line-endings2.expected.dump
? subversion/tests/cmdline/svnsync_tests_data/copy-bad-line-endings2.dump
? subversion/tests/cmdline/svnsync_tests_data/.gitattributes
? subversion/tests/cmdline/svnsync_tests_data/copy-bad-encoding.dump
? subversion/tests/cmdline/svnsync_tests_data/copy-bad-encoding.expected.dump
? subversion/tests/cmdline/svnrdump_tests_data/copy-bad-line-endings2.dump
? subversion/tests/cmdline/svnrdump_tests_data/copy-bad-line-endings2.expected.dump
? subversion/tests/cmdline/svnrdump_tests_data/.gitattributes
M subversion/svnsync/sync.h
M subversion/svnsync/main.c
M subversion/svnsync/sync.c
M tools/buildbot/slaves/xp-vc60-ia32/config.bat.tmpl
M packages/windows-WiX/BuildSubversion/WixDialog/build.bat
Re: Bug? svn update --accept mine-full fails if an added file exists
unversioned in the working copy
Posted by Stefan Sperling <st...@elego.de>.
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.