Re: [Subclipse-dev] giving a shot at fixing deletions

On Fri, Jul 11, 2008 at 2:56 PM, Hugo Visser <joegi_at_scene.nl> wrote:

>> 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 the
> menu.
>
> 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 Test.java
> 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.

The problem in these examples is, as you point out, that Subclipse is
doing the right thing. So in the attempt to make these scenarios
better you have to be careful to not break the cases where it really
is the right thing.

The next problem is that Subclipse has to work within the confines of
what Subversion and Eclipse allow it to do. For example, following up
those svn delete's with svn add's will not do the right thing. It
will preserve the files, but it will break the history. So you really
have to undo the delete, by using revert. The problem there is that
it is going to put back the old files. So now you need to save the
current files and put those back after the revert. It all gets very
ugly fast.

This would be my suggestion:

1) Ignore the case where the user deleted something. That is complete
user error. I do not see any way to fix that and how many times is
the user going to make that mistake?

2) On the Eclipse copy problem, look for a solution at the point of
the problem. Figure out a way to know that a copy is happening and
then ignore the delete. Maybe there is a way to peek ahead in the
resource delta and see that an Add of the same file is coming. Or
maybe when we receive a delete there is a way to add our processing to
some job queue so that it if there is an Add coming, our code happens
after the Add. At which point when our code runs we can now see that
the Add happened and just skip the delete.

A final idea is that maybe there are some new options that could be
created to fixup the problem after it happens? Detect when a file or
folder is scheduled for delete but in actuality a new copy exists and
then provide options that can do something to fix it? The variation
this is adding is that it would allow you to work around any problems
that might exist in trying to detect the problem when it is happening.
 This would also help with your example of when a user deletes
something they plan to regenerate later.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org