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
Received on Fri Jun 11 04:14:09 2004