> I'd start by explaining the problem you are trying to solve. What
> needs to be fixed about deletions?
> Following a delete with an add is not a solution. That does not turn
> it back into a modification, it turns it into a replace, which means a
> new line of history is created.
Two seperate cases I guess. When a resource is copied over an existing
one, it is marked as deleted and when committed it is unversioned or
actually deleted. But when testing now (writing this email) it doesn't
seem to be an issue with Eclipse 3.4 and the latest release. But at
work we use RAD 7 (based on 3.2) so I have to retest that.
Secondly today a team member deleted a package in the source tree with
the intent to regenerate or copy some other contents into the tree. So
this is what happens. He deletes the package --> subclipse deletes the
files and marks the package as deleted (as expected). Then he
generates some source recreating the previously deleted package. When
refreshing the workspace stuff is marked as deleted (which I can still
understand from SVN's point of view but this already confused my
collegue). When he commits the files are gone. Again, I understand how
SVN works and that this is as designed, but from the users perspective
it would be better for subclipse or Eclipse to notice that the
previously deleted stuff now reappeared and "undo" the delete
administration. This seems a logical approach to me because the users
intent was actually not to delete the files, but to modify the files.
Another option would be to allow the user to do this manually using
I'll try to summerize the steps to reproduce a slightly different case
1. Have a package "test.sub1.sub2" containing Test.java
2. Delete the entire sub2 package
3. Add the sub2 and Test.java again, both are marked deleted.
4. Revert the deletion of the sub2 package only, keeping the new
5. Test.java is still marked deleted. On commit the file is
unversioned and can be readded.
If you skip 4 then Test.java is also deleted since that is scheduled.
I don't know if that makes sense in any way. I'm pretty sure that
subclipse is technically doing the right thing. A workaround would be
committing after the package delete, but that would not be optimal,
because that would force the user to commit non-working code.
Anyway, if help is needed on this or other parts of subclipse I'd like
to jump in and help if I can. I like subclipse and I love to be able
to help it get even better.
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-07-11 20:57:15 CEST