Re: svn issues
Sadly, I think the only way to do it is: find openjpa-*/src -path '*/.svn' -prune -o -type f -print | xargs -e grep -l '@since' On Aug 30, 2006, at 9:57 AM, Patrick Linskey wrote: Hey, Frustratingly, things like 'grep -l @since openjpa-*/src | xargs sed ...' don't have quite the intended effect, since that search will find files in the .svn directory. Does anyone know of a clever way to work around this (other than tossing a 'grep -v .svn' into the middle)? I've screwed up my .svn files twice so far -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn issues
Something like this might be handy: find . ! ( -path */.svn/* ) -exec sed ... ; -print as it won't descend into .svn directories. Or something that just greps *.java extensions since SVN stores its work files as *.java.svn-work: find . -name *.java -exec sed ... ; -print These have scaled pretty well for me in big code bases. Eddie On 8/30/06, Patrick Linskey [EMAIL PROTECTED] wrote: Hey, Frustratingly, things like 'grep -l @since openjpa-*/src | xargs sed ...' don't have quite the intended effect, since that search will find files in the .svn directory. Does anyone know of a clever way to work around this (other than tossing a 'grep -v .svn' into the middle)? I've screwed up my .svn files twice so far -Patrick -- Patrick Linskey BEA Systems, Inc. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: svn issues
Note that there is a proposed patch to grep to address this sort of problem. You can vote for it (registration required) at: http://savannah.gnu.org/bugs/? func=detailitemitem_id=11017#dependencies On Aug 30, 2006, at 10:20 AM, Eddie O'Neil wrote: Something like this might be handy: find . ! ( -path */.svn/* ) -exec sed ... ; -print as it won't descend into .svn directories. Or something that just greps *.java extensions since SVN stores its work files as *.java.svn-work: find . -name *.java -exec sed ... ; -print These have scaled pretty well for me in big code bases. Eddie On 8/30/06, Patrick Linskey [EMAIL PROTECTED] wrote: Hey, Frustratingly, things like 'grep -l @since openjpa-*/src | xargs sed ...' don't have quite the intended effect, since that search will find files in the .svn directory. Does anyone know of a clever way to work around this (other than tossing a 'grep -v .svn' into the middle)? I've screwed up my .svn files twice so far -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: svn issues
Sweet! This is more what I was hoping for. Between now and 2017 when this gets addressed, I guess I'll just create wrapper scripts for grep and egrep. (The find / grep type solutions are easy, but require that I remember to filter out .svn. Often I don't remember that until too late.) -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, August 30, 2006 10:35 AM To: open-jpa-dev@incubator.apache.org Subject: Re: svn issues Note that there is a proposed patch to grep to address this sort of problem. You can vote for it (registration required) at: http://savannah.gnu.org/bugs/? func=detailitemitem_id=11017#dependencies On Aug 30, 2006, at 10:20 AM, Eddie O'Neil wrote: Something like this might be handy: find . ! ( -path */.svn/* ) -exec sed ... ; -print as it won't descend into .svn directories. Or something that just greps *.java extensions since SVN stores its work files as *.java.svn-work: find . -name *.java -exec sed ... ; -print These have scaled pretty well for me in big code bases. Eddie On 8/30/06, Patrick Linskey [EMAIL PROTECTED] wrote: Hey, Frustratingly, things like 'grep -l @since openjpa-*/src | xargs sed ...' don't have quite the intended effect, since that search will find files in the .svn directory. Does anyone know of a clever way to work around this (other than tossing a 'grep -v .svn' into the middle)? I've screwed up my .svn files twice so far -Patrick -- Patrick Linskey BEA Systems, Inc. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. smime.p7s Description: S/MIME cryptographic signature