Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.1.x
Description
This was initially discovered while accidentally moving externals, but as Philip
Martin pointed out: "it will occur whenever someone attempts to "svn move" or
"svn rm" a working copy root nested within another working copy"
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,
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!
Original issue reported by luebbe