RE: [Subclipse-users] eclipse + subeclipse + javacc - ingoring auto-generated java code.

Update,

  I have pondered what Mark stated and changed the logic a bit and it seems to work and is "performent", (i.e. no material extra time taken). Actually after doing a bit of fooling around, I changed the order of the boolean expression in a few places and it solved the problem I was trying to address. The is, when a file has been marked as managed (i.e. under control of SVN) and is also derived still decorate the file (resource). The current implementation did not do that all the time, it ignored the resource (from a UI perspective) due to the way the boolean conditions were written under certain conditions. When a file that is derived (generated code by RAD) has been altered it lost it's decoration; now with my change it will be decorated correctly (99% of the time).

  Bottom line, if a resource is managed honour that state (do not ignore it) ...

  There is one problem that I am having and that has to do with the decoration of derived files when scheduled to be added to the repo (i.e. add to version control). They are being marked as dirty (dirty icon) which is a true state, but they should have the plus icon for added state. When I do a synchronize it shows up correctly. Mark, any hints as to where I can start looking :-) or why this is occurring. Thx a bunch ...

dwfa

-----Original Message-----
From: Acheson, Douglas
Sent: 2008, July, 07 10:36 AM
To: users_at_subclipse.tigris.org
Subject: RE: [Subclipse-users] eclipse + subeclipse + javacc - ingoring auto-generated java code.

Yes, I found out the performance issue :-( on Friday (being in Canada I do not get the 4th of July off). I believe I have a solution to resolve the performance problem. Just working on that now. Changing the order has its own problem.

I will reply with more details in a bit ...

dwfa

-----Original Message-----
From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: 2008, July, 07 10:30 AM
To: users_at_subclipse.tigris.org
Subject: Re: [Subclipse-users] eclipse + subeclipse + javacc - ingoring auto-generated java code.

On Mon, Jul 7, 2008 at 10:19 AM, Acheson, Douglas <douglas.acheson_at_rbc.com> wrote:
> As I have found ,the derived flag is turned on by the creator (most
> likely) of the file. I am writing a patch/fix that is similar to the
> defer delete file; if a certain svn property is found (prolly
> ignoreIsDerived) it will ignore the isDerived flag (hope that makes
> sense)

I do not think that is the way to go. This flag is checked too often to lookup a property value each time.

If you want to make a patch, what I would recommend is that you look at everywhere we look at the flag and in most cases change the order.
We almost always look at it before anything else. You'd want to instead have the normal Subversion status lookups happen and only when the status is UNVERSIONED would you want to check if it is derived.
In that case, if it is derived, then you would change the status to IGNORED.

You would really need to do this everywhere the flag is checked.

--
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
_______________________________________________________________________
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