Comment 1 Adam Kiezun 2003-01-30 09:41:22 EST

(same problem with copy)

in IResource, FORCE means that things out of synch will be copied too
so it does not mean, i think, that things will be ovewritten. which, in turn, 
means, that NAME_COLLISION has little to do with the FORCE flag.

ISourceManipulation.copy/move had something like 'replace' - and there the 
NAME_COLLISION made sense.

Comment 2 Adam Kiezun 2003-01-30 09:46:22 EST

major - makes clients have to delete the conflicting resource themselves

Comment 3 Jerome Lanneluc 2003-01-30 10:48:07 EST

Right, I'm going to add a REPLACE flag.

Otherwise for the message, are you using getMessage() or getString(). The later 
is deprecated.

Comment 4 Jerome Lanneluc 2003-01-31 04:02:40 EST

REPLACE flag added. Also improved message of JavaModelException.

Added regression tests on RootModificationTests:
testCopySourceFolder5()
testFailCopySourceFolder1()
testFailCopySourceFolder2()

Comment 5 Adam Kiezun 2003-01-31 08:22:12 EST

was this in the code you sent to us last night?
(i still get the exception) although i pass REPLACE

Comment 6 Adam Kiezun 2003-01-31 08:34:45 EST

this line in CopyPackageFragmentRootOperation::verify() looks incorrect:
it ignore the REPLACE flag

if (foundExistingEntry && (this.updateResourceFlags & IResource.FORCE) == 0) {
						return new JavaModelStatus
(IJavaModelStatusConstants.NAME_COLLISION, this.destination.toString());
					}

Comment 7 Jerome Lanneluc 2003-01-31 13:07:48 EST

Sorry about that. This is fixed in HEAD.

Comment 8 David Audel 2003-02-11 09:50:50 EST

tests are on RootManipulationsTests.

Verified.