RE: [Subclipse-users] Issue with RAD 7 generated code

Thx for the response Mark, I tried setting the directory property on
the topmost source directory of the EJB project and it still behaves the
same. I have tried it with a version 1.5 of the SVN server and 1.2 of
the client as well as 1.4 of the client both using JavaHL. I end up
with the same result. BTW I am using RAD 7.0.0.3 (sry for the typo).

dwfa

-----Original Message-----
From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: 2008, June, 26 11:47 AM
To: users_at_subclipse.tigris.org
Subject: Re: [Subclipse-users] Issue with RAD 7 generated code

On Wed, Jun 25, 2008 at 4:10 PM, Acheson, Douglas
<douglas.acheson_at_rbc.com> wrote:

> I am using RAD 7 (v7.0.3) with the new subclipse v1.5.0 plugin
> against a svn (v1.5.0) repo using web_dav (the Collaba release) on
> Windows XP sp2. I have created an EJB project and it contains a
> stateless session EJB. I check in all the generated code to SVN and
all
> is good. When I tell RAD to prepare the EJB for deployment it
> regenerates code (the stubs and skels etc) - basically runs rmic
again.
> At this point the RAD replaces those files new ones with the same
names.
> Now when I look at the artifacts from the Package Explorer they do not
> show up as versioned elements nor (cylinder) as non-versioned elements
> (with ?) (i.e. no label decoration).

Sometime before 1.0 I think we added a way to handle tools like these
from IBM which generate files by deleting and recreating them. The
problem is that these tools do it with Eclipse API's and so Eclipse
tells us the file is deleted and we run svn delete. What we did was
we allow you to add a Subversion property named "DeferFileDelete" with
a value of "true". You can set this on a parent folder of the
generated files. When this property is set, Subclipse will ignore any
Deletes that are sent for files beneath the folder with the property.

This is a versioned property, so you must commit it. With this in
place, we will just treat these files as modifications as they should
be.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
_______________________________________________________________________
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations.
Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.  
Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org