kfogel@collab.net writes:
> Lübbe Onken <l.onken@rac.de> writes:
>> consider the following situation:
>> your WC is in myProject, myproject contains a subfolder named "foo"
>> Set svn:externals on myProject to "bar http://some/location", commit
>> your changes and update your working copy.
>> You now got:
>> myProject/foo
>> myProject/bar (External)
>>
>> now do 'svn move bar foo' You get:
>> A foo/bar
>> D bar/...
>> ...A lot of files and folders inside bar...
>> D
>> svn: 'bar' is not under version control,
The 'not under version control' error is not specific to svn:external,
it will occur whenever someone attempts to "svn move" or "svn rm" a
working copy root nested within another working copy. I'm not exactly
sure how the client should handle such a request on a working copy
root, perhaps they should be rejected? If a working copy root does
get scheduled for deletion the entire working copy needs to vanish
when the delete is committed.
>> but the move has taken place!
>>
>> 'svn st -v' shows you:
>> X bar
>> foo
>> A + foo\folder
>> + foo\...
>> Performing status on external item at 'bar'
>> D bar
>> D bar\folder
>> D bar\...
>>
>> Now I didn't dare to commit this, because I'm afraid that the
>> scheduled deletion really is going to kill files from my separate
>> repository for the "bar" project. The files in bar are now scheduled
>> for addition to myproject\foo\bar, so the external property is lost.
>>
>> Luckily enough there's a nice 'revert' function, but I think that 'svn
>> moving' externals should be disabled / discouraged / warned in the
>> first place. 'svn copy' externals is fine, but moving externals should
>> be forbidden or only allowed with --force because this results in a
>> deletion in one repository and an addition in another
>> repository. Dangerous!
>
> At least it should be forbidden without --force, until we get
> cross-repository history implemented :-).
The first question is what is "svn move foo bar" supposed to do when
the foo or bar is part of an svn:external. Are people expecting the
svn:external property to get modified? It's not always
cross-repository either, the svn:external could refer to another part
of the same repository. The same question applies to "svn rm foo"
when foo is part of svn:external.
One solution is simply to prohibit move and rm on working copy roots
whether or not they are part of an svn:external. This would be a
slight reduction in functionality as at present it is possible to
delete a wc root, by nesting it within another wc, and to commit the
deletion. However it's not particulary useful feature because the
delete gives the 'not under version control' error and although the
commit succeeds server-side it fails client-side during post-commit
processing.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 22 20:08:07 2004