Ok. A less solvable problem will be if this tool is deleting
folders. If that is the case, you will not be able to version these
files.
Sent from my iPhone
On Jun 27, 2008, at 10:58 AM, "Acheson, Douglas" <douglas.acheson_at_rbc.com
> wrote:
> 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 rappor
> tent.
> 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 a
> viser immédiatement, par retour de courrier électronique ou par un a
> utre moyen.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
> For additional commands, e-mail: users-help_at_subclipse.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-06-28 01:45:38 CEST