Re: svn issues

2006-08-30 Thread Marc Prud'hommeaux


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

2006-08-30 Thread Eddie O'Neil

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

2006-08-30 Thread Marc Prud'hommeaux


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

2006-08-30 Thread Patrick Linskey
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