Finding shallowest instance of $foo in a given structure

I've presented myself with an interesting (to me) problem
that I can't
seem to address with find; an alternative would be a
trivially short
script, but I'm being stubborn for the moment.  I'll try to
make this
short.

In tracking multiple OSS projects, I've collected a src/
directory
full of various repositories I'd like to keep up-to-date.
Unfortunately, there is little standardization on  either
VCS or code
tree hygeine, and synchronizing them all is growing both
time-consuming and tiresome.  In short, I'm looking for a
clean way to
find the shallowest 'CVS', '.svn', or what have you in a
given
directory structure without ignoring sibling directories. 
If a
project publishes multiple trees (trunk, branch, etc.) with
no common
VCS parent, it's difficult to cleanly categorize and/or
store them
without causing headaches, and for obvious reasons, I'm not
up for
starting source-management wars with a dozen different
maintainers.

I've nearly gotten where I want with -prune but only in a
crufty
manner (i.e. 'find $ -type d ! -name . -exec [ -e
"{}/.svn" ] ;
-print -prune') that makes searching large, heterogeneous
trees
painful (no need to search .git repositories for .svn or
CVS).  It
seems like I'm just not seeing the obvious, that there's a
right way
to do this in an efficient and elegant manner.  I've
experimented with
several variations, but most either print every $foo in the
structure
or ignore siblings (project/trunk/$foo,
project/branches/$foo), or
even worse depend on brittle -maxdepth and -mindepth
statements.  I
could group projects in directories according to VCS instead
of
category, or any number of other similarly ugly hacks, but
believe
there should be a better way.

Random conjecture here: what if -prune would accept an
integer
argument (0 as a default) as a representative of how many
parent
directories to actually prune?  Would that be a viable
pursuit, or is
there a better way to do what I'm trying?

Thanks for your time!


RB

RB wrote:
> In short, I'm looking for a clean way to find the
shallowest 'CVS',
> '.svn', or what have you in a given directory structure
without
> ignoring sibling directories.  If a project publishes
multiple trees
> (trunk, branch, etc.) with no common VCS parent, it's
difficult to
> cleanly categorize and/or store them without causing
headaches, and
> for obvious reasons, I'm not up for starting
source-management wars
> with a dozen different maintainers.

Your problem sounds interesting to me as well.  But I don't
quite
understand it.  Is this following a representative test
case?

  mkdir -p srcdir/proj1/CVS
  mkdir -p srcdir/proj1/foo1dir/CVS
  touch srcdir/proj1/foo1dir/foo
  mkdir -p srcdir/proj2/CVS
  mkdir -p srcdir/proj2/foo2dir/CVS
  touch srcdir/proj2/foo srcdir/proj2/foo2dir/bar
  mkdir -p srcdir/proj3/.svn
  mkdir -p srcdir/proj3/foo3dir/.svn
  touch srcdir/proj3/foo srcdir/proj3/foo3dir/bar
  mkdir -p srcdir/proj4/.git
  mkdir -p srcdir/proj4/foo3dir
  touch srcdir/proj4/foo srcdir/proj4/foo3dir/bar
  mkdir -p srcdir/subdir/proj5/.svn
  mkdir -p srcdir/subdir/proj5/foo5dir
  mkdir -p srcdir/subdir/proj6/.svn

Given that you are looking to list out the following
directories?

  srcdir/proj1/CVS
  srcdir/proj2/CVS
  srcdir/proj3/.svn
  srcdir/proj4/.git
  srcdir/subdir/proj5/.svn
  srcdir/subdir/proj6/.svn

Is that right?

> I've nearly gotten where I want with -prune but only in
a crufty
> manner (i.e. 'find $ -type d ! -name . -exec [ -e
"{}/.svn" ] ;
> -print -prune') that makes searching large,
heterogeneous trees
> painful (no need to search .git repositories for .svn
or CVS).

Using the above test case the following seems to work.

  find srcdir ( -exec test -d {}/CVS ; -o -exec test -d
{}/.svn ; -o -exec test -d {}/.git ; ) -print -prune |
sort

Produces:

  srcdir/proj1
  srcdir/proj2
  srcdir/proj3
  srcdir/proj4
  srcdir/subdir/proj5
  srcdir/subdir/proj6

Is that what you are looking for?

Bob

>  Is that right?
That is correct, but having failed to apply basic shortcut
logic with
parentheses and '-o', my search was painfully slow when
testing due to
using only a single subtype (hint: follow your own
requirements).
Hence, I presumed early on that -exec was the wrong way to
go and
chased other rabbit trails.

> Using the above test case the following seems to work.
>
>   find srcdir ( -exec test -d {}/CVS ; -o -exec test
-d {}/.svn ; -o -exec test -d {}/.git ; ) -print -prune |
sort

That works for me as well; I knew I had to be a few
sandwiches short!
It also has the added benefit of being able to embed update
statements
per VCS type, so I can cron this nicely and forget about it.
 Thanks!


RB

RB wrote:
> > Using the above test case the following seems to
work.
> >
> >   find srcdir ( -exec test -d {}/CVS ; -o -exec
test -d {}/.svn ; -o -exec test -d {}/.git ; ) -print
-prune | sort
> 
> That works for me as well; I knew I had to be a few
sandwiches short!
> It also has the added benefit of being able to embed
update statements
> per VCS type, so I can cron this nicely and forget
about it.  Thanks!

I am often in need of a hint.  Glad that I was able to
help.

Bob

I also think this is an interesting example.  The
documentation needs
a few more good examples.

Would the two of you be able to be able to pull this into a
(what-I-wanted-to-achieve, command,
explanation-of-how-it-works) form
so that we can put it into the Texinfo documenation?   (And,
length
permitting, the manual page).

James.

>  Would the two of you be able to be able to pull this
into a
>  (what-I-wanted-to-achieve, command,
explanation-of-how-it-works) form
>  so that we can put it into the Texinfo documenation?  
(And, length
>  permitting, the manual page).

Never done a Texinfo doc, but no better time to learn than
now.  Will
put something together in the next couple of nights and
report back.


RB

On Wed, Mar 19, 2008 at 8:48 PM, RB <aoz.syngmail.com> wrote:
> >  Would the two of you be able to be able to pull
this into a
>  >  (what-I-wanted-to-achieve, command,
explanation-of-how-it-works) form
>  >  so that we can put it into the Texinfo
documenation?   (And, length
>  >  permitting, the manual page).
>
>  Never done a Texinfo doc, but no better time to learn
than now.  Will
>  put something together in the next couple of nights
and report back.

ASCII is also perfectly OK, I can add the markup quite
easily myself
if you'd prefer.   It's coming up with good and
to-the-point
explanatory text that's the challenge.

James.

RB wrote:
> >  Would the two of you be able to be able to pull
this into a
> >  (what-I-wanted-to-achieve, command,
explanation-of-how-it-works) form
> >  so that we can put it into the Texinfo
documenation?   (And, length
> >  permitting, the manual page).
> 
> Never done a Texinfo doc, but no better time to learn
than now.  Will
> put something together in the next couple of nights and
report back.

Great!  A wide variety of examples definitely are good to
have in the
documentation.  I would be willing to help as well.

Bob

>  Would the two of you be able to be able to pull this
into a
>  (what-I-wanted-to-achieve, command,
explanation-of-how-it-works) form
>  so that we can put it into the Texinfo documenation?  
(And, length
>  permitting, the manual page).

Since I was already familiar with manual page syntax and
aspire to
terseness, here's a preliminary stab at what *might* work
for that.
Please criticize or modify as needed; I'm not attached to
much of my
work.

I'm assuming the Texinfo page would need to be a little
more
explanatory and should stylistically fit with section 8 or
9; is that
the case?

Following is a patch against find.1 from findutils-4.3.13:

--- find.1.orig 2008-03-19 22:22:50.240612504 -0600
+++ find.1      2008-03-19 22:56:23.749388656 -0600
 -1903,6
+1903,22 
 this is the default anyway, but the parentheses help to
show
 what is going on.

+.P
+.nf
+.B find repo/ e( -exec [ -d {}/.svn ] e; -o -exec [
-d
{}/.git ] e; e) -print -prune
+
+.fi
+Search for the roots of specific SCM repositories in an
efficient
+manner.  As opposed to the prior example, the parentheses
play
+a critical role in combination with
+.B -prune
+to prevent descent into directories that have already been
+discovered.  A more general way to express this behavior
is
+"Find the shallowest instances of repeated leaf nodes
in a
+given tree."  This example was derived from a need to
maintain
+source synchronization with multiple projects that used
+varying SCM tools and tree management ideologies.
+
 .SH EXIT STATUS
 .PP
 .B find

On Thu, Mar 20, 2008 at 4:59 AM, RB <aoz.syngmail.com> wrote:
>  I'm assuming the Texinfo page would need to be a
little more
>  explanatory and should stylistically fit with section
8 or 9; is that
>  the case?

Yes.   I'd be rather in favour of 9, "Worked
Examples".

>
>  Following is a patch against find.1 from
findutils-4.3.13:
>
>  --- find.1.orig 2008-03-19 22:22:50.240612504 -0600
>  +++ find.1      2008-03-19 22:56:23.749388656 -0600
>   -1903,6 +1903,22 
>   this is the default anyway, but the parentheses help
to show
>   what is going on.
>
>  +.P
>  +.nf
>  +.B find repo/ e( -exec [ -d {}/.svn ] e; -o
-exec [ -d
>  {}/.git ] e; e) -print -prune
>  +
>  +.fi
>  +Search for the roots of specific SCM repositories in
an efficient
>  +manner.

It might help the reader to visualise what's going on if we
mention
what the approximate arrangement of the tree being searched
is.

> [...] As opposed to the prior example, the parentheses
play
>  +a critical role in combination with
>  +.B -prune
>  +to prevent descent into directories that have already
been
>  +discovered.  A more general way to express this
behavior is
>  +"Find the shallowest instances of repeated leaf
nodes in a
>  +given tree."

>    This example was derived from a need to maintain
>  +source synchronization with multiple projects that
used
>  +varying SCM tools and tree management ideologies.

Not sure that last sentence adds much, even though I asked
you to
indicate the motivation.

On the subject of the command itself, it's worth considering
using
just one -exec per directory:
find repo/ ( -exec test -d {}/.svn -o -d {}/.git -o -d
{}/CVS ; )
-print -prune

...or descending one level further and snipping the leaf
name off with -printf:
find repo/ -type d ( -name .svn -o -name .git -o -name CVS
) -printf
"%hn" -prune