>>
>
> 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.
Maybe as a first pass it would be acceptable to make this a manual
action, which would work for the other scenario too I guess.
> 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.
Yes, the latter is the approach I'm thinking of now. Some kind of
"oops I screwed up, help me" option :) I'll dive into the code to see
if I can make the simplest scenario work and to understand how things
fit together in the plugincode. And I guess I can educate the team
members not to delete the packages and if they do, revert the package
without the deleted files.
Thanks,
Hugo
---------------------------------------------------------------------
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 21:39:32 CEST