Could you add all this to issue tracker at
http://subclipse.tigris.org/servlets/ProjectIssues
?
Thanks,
Cédric
>I have a potentially tough one, hopefully there is a way to solve this.
>
>A number of the tools that IBM provide in their Eclipse-based IDE's
>generate code, typically Java or JSP but that does not really matter. The
>problem is that when you make changes these code generators typically
>operate by first deleting the previously generated files and then
>generating the new ones to replace them. This can cause a problem to
>Eclipse Team providers as they are sent a delete followed by an add and
>the API has no mechanism for saying it is in effect an update. Of course
>it is also possible that the generator will generate more or less files
>that before, in which case some of those files will stay deleted.
>
>The CVS provider does not have a problem with this because it does not
>seem to try to figure anything out until you do a commit. Locking
>providers like PVCS typically step in at the Delete and force a delete
>from the repository, they then see the Add as a brand new file that is not
>connected to the new file.
>
>Subclipse seems to hang on to that delete notification so that when I
>later commit it deletes the files from the repository, and I do not think
>you can delete and add the same file from a WC without a commit so it gets
>kind of messed up. Even if it didn't the delete followed by add would not
>be what you wanted.
>
>It would be nice if Subversion had some mechanism to defer whatever it
>needs to do until commit time and then figure things out then. It would
>then see these files as having been updated, as opposed to deleted. When
>I was working with PVCS, I had an idea of possibly maintaining some sort
>of "delete queue" kind of like a trash can. When a new file was added, if
>there was a copy in the delete queue, the item could just be removed from
>the queue. When a commit was performed, any files left in the delete
>queue would be deleted.
>
>I have seen messages related to this on the eclipse.team mailing list as I
>think it provides problems for all Locking providers. So the problem is
>not uncommon. It would be nice if there were some way that Subclipse
>could handle this scenario as I do not think it will be that uncommon.
>
>Thanks
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
>
>
Received on Fri Jun 11 09:55:25 2004