Behavior of -N for svnlook

[William Nagel <bi...@stagelogic.com>]

I'm working on a patch for svnlook to add a --non-recursive option  
and the ideal behavior is unclear, so I'm looking for comments on how  
it should work.

My initial thought is that it should print the contents of the  
directory supplied by the path argument, both files and directories,  
without descending into any contained directories.  That's the  
behavior of the patch I posted last week, and seems to be the most  
useful for the way "svnlook tree" is used.  However, as Karl Fogel  
pointed out, that is not the behavior of -N in the svn commands,  
which completely omit all directories.

Does anyone have any thoughts on which behavior would be best (or any  
alternate suggestions)?

-Bill Nagel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Behavior of -N for svnlook

[Karl Fogel <kf...@red-bean.com>]

William Nagel <bi...@stagelogic.com> writes:
> I'm working on a patch for svnlook to add a --non-recursive option
> and the ideal behavior is unclear, so I'm looking for comments on how
> it should work.
>
> My initial thought is that it should print the contents of the
> directory supplied by the path argument, both files and directories,
> without descending into any contained directories.  That's the
> behavior of the patch I posted last week, and seems to be the most
> useful for the way "svnlook tree" is used.  However, as Karl Fogel
> pointed out, that is not the behavior of -N in the svn commands,
> which completely omit all directories.
>
> Does anyone have any thoughts on which behavior would be best (or any
> alternate suggestions)?

I think that the patch's current behavior is still sensible, even
though inconsistent with -N's meaning elsewhere in Subversion.  After
all, svnlook is just listing contents, not creating objects on disk.
It's hard to see any benefit to omitting subdirectories from that
listing.

   "A foolish consistency is the hobgoblin of little minds."
                                  -- Samuel Johnson

   "If I have seen farther than others, it is only by standing on the
    shoulders of giants."
                                  -- attributed to Isaac Newton

   "Foolish hobgoblins with giant minds consistently stand on my
    shoulders."
                                  -- svnlook

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Behavior of -N for svnlook

[Karl Fogel <kf...@red-bean.com>]

"C. Michael Pilato" <cm...@collab.net> writes:
> I think Karl is mistaken.  Both 'svn list' and 'svn status' behave in the
> way you describe:
>
> % svn ls
> dir2/
> new-file/
> new-file-2
> $ svn st -Nqv
>                11       11 cmpilato     .
>                11        3 cmpilato     dir2
>                11       11 cmpilato     new-file-2
>                11       10 cmpilato     new-file
> $

Ah -- then our -N was already inconsistent, in a sense, but sticking
with the current inconsistency would be the most consistent thing to
do.  So the current behavior of the patch is fine!

> The benefit of this definition of "non-recursive" is that folks can use many
> non-recursive runs to build a recursive one.  By parsing the output of
> 'svnlook tree -N', they can iterate over display paths that end in a slash
> (/) and recurse into those paths.  The file-children-only definition of
> non-recursive does not permit this discovery.

Agreed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Behavior of -N for svnlook

["C. Michael Pilato" <cm...@collab.net>]

William Nagel wrote:
> I'm working on a patch for svnlook to add a --non-recursive option and
> the ideal behavior is unclear, so I'm looking for comments on how it
> should work.
> 
> My initial thought is that it should print the contents of the directory
> supplied by the path argument, both files and directories, without
> descending into any contained directories.  That's the behavior of the
> patch I posted last week, and seems to be the most useful for the way
> "svnlook tree" is used.  However, as Karl Fogel pointed out, that is not
> the behavior of -N in the svn commands, which completely omit all
> directories.

I think Karl is mistaken.  Both 'svn list' and 'svn status' behave in the
way you describe:

% svn ls
dir2/
new-file/
new-file-2
$ svn st -Nqv
               11       11 cmpilato     .
               11        3 cmpilato     dir2
               11       11 cmpilato     new-file-2
               11       10 cmpilato     new-file
$

> Does anyone have any thoughts on which behavior would be best (or any
> alternate suggestions)?

Go with your gut, man!

The benefit of this definition of "non-recursive" is that folks can use many
non-recursive runs to build a recursive one.  By parsing the output of
'svnlook tree -N', they can iterate over display paths that end in a slash
(/) and recurse into those paths.  The file-children-only definition of
non-recursive does not permit this discovery.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand