Just to follow up on this issue, before anyone runs off and sets the
DeferFileDelete property on all of their projects, please keep in mind
that this feature was added to solve two very specific scenarios where it
was expected that the delete was going to be immediately followed up with
a new file.
1) Say you build a JAR file in one project and then want to drag and drop
it to another project that uses it. I do this with JavaSVN and Subclipse.
If you do the drag and drop from Windows to Eclipse it works great. If
you do it from one Eclipse project to another, for some reason Eclipse
sends through a delete request. So adding this property to a "lib" folder
can prevent this problem.
2) Many of my customers use a tool from IBM which generates JSP's from
legacy "green-screen" apps. When this tool regenerates the JSP, it first
deletes them and recreates them, which is not unreasonable to do. But
since this is an Eclipse-based tool, Eclipse sees the delete and notifies
Subclipse. So users of this tool, and any other like it, can set the
property to avoid problems.
The more common use case for a delete is that the file is really meant to
be deleted. In that scenario, this property can still work for you, it
just is not ideal. For example, if you were to do an update, before doing
a commit, I believe the update process may restore missing files. There
is a way around this problem though. The Show Pending Operations view
will show missing files, and for those files, there is a Mark as Deleted
option available from that view which will run the svn delete command so
that the delete is registered with Subversion. If you are going to use
this feature, I would recommend that you either use this feature to mark
your deletes, or commit the deletes soon.
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
Received on Tue Mar 7 02:33:50 2006