Mark,
I did some more testing and I guess it's an Eclipse bug. This is what I
did to reproduce it.
Add test.jar to a folder lib and commit it. The test.jar is now version
controlled.
Create a second test.jar and copy it from my desktop to the Eclipse
project. The test.jar file is now decorated as modified (as expected).
Then I copied the test.jar to the root of my Eclipse project and then
copied it over the test.jar in de lib folder -> The file is marked as
deleted, the svn console shows the delete command. After commit the file
is not gone, but only removed from svn.
So it seems to be happening only when copying from within Eclipse. I've
tested it with subclipse 0.9.31 and the behaviour is the same. In 0.9.31
the decorator for modified is the same as deleted so maybe I didn't
notice before. So I guess it is an Eclipse bug. The version of Eclipse I
tested is 3.1.
Maybe it is possible to workaround this bug? For example if Eclipse
indicates the file is deleted, check if the file exists, if so it is
either overwritten by the same version or by a different version. If it
does not exist then it's really deleted.
BTW I'm happy that the overwritten file is not really deleted but just
marked as deleted, I can just add it again and commit.
I'll test some more this weekend with newer and older Eclipse versions.
Hugo
Mark Phippard wrote:
>>Is there any (easy) way confirm that this is either an Eclipse or
>
> subclipse
>
>>bug? It's really annoying because now I have to revert the overwrite,
>
>
> It seems like it has to be a Subclipse bug because it is not consistent. I
> have been doing this in Eclipse 3.0 recently and have not been having the
> problem though.
>
> It still seems that it must be an Eclipse bug, I just cannot see how. Here
> is why. In theory, I think the only code we have that does an svn delete
> is the MoveDeleteHook. Eclipse is responsible for calling this hook, not
> us. If Eclipse is calling it when it shouldn't, then it is their bug. It
> should just be a normal file update scenario where our code is not
> triggered at all, other than our ResourceChangeListener to update our
> decorators.
>
> You can try checking out our core and ui projects and searching for the
> calls to svn delete. Maybe there is another scenario I am not aware of.
> But if it is the MoveDeleteHook, then it is an Eclipse bug. Also, if it is
> the MoveDeleteHook, then I have a change in trunk where you can tell
> Subclipse to ignore deletes. You can then manually do the delete at commit
> time if the file is still "missing".
>
> Mark
>
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
Received on Sun Nov 27 01:04:46 2005