[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 1269 - trunk/subversion/clients/cmdline

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-02-14 14:16:09 CET

On Wed, Feb 13, 2002 at 10:46:54PM -0600, Karl Fogel wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
> > > > the names of the properties, unless '--recursive' is specified. 'svn propget'
> > > > will only print the values, and will only print the filenames if there is
> > > > more than one target or '--recursive' was specified and svn_client_propget
> > > > returned multiple files that matched that property.
> > >
> > > Hmmm. Why use `recursive' to mean `verbose' when we already have a
> > > verbose option available?
> >
> > oops, error in the log there. 'svn proplist' prints the names unless
> > 'verbose' is specified, not 'recursive'. my bad. the code checks for
> > verbose.
>
> Ah, good. (I hadn't looked at the commit itself yet).
>
> As long as you're fixing the log msg, change "filenames" to
> "propnames", I think?

nope, it really is 'filenames', not 'propnames', for pget. pget only
takes a single propname, as noted by gstein in the issue, so we
already know what property we're looking for, so why bother printing
it. the problem is that we can potentially be printing out the
information for more than one file, and if so, we need to include the
filename for each one, so you can tell which file has which value set
for whatever property you're looking for.

well, i suppose technically one could argue that we should be using
'target', rather than 'filename', since you can set properties on both
files and directories, but at this point we're splitting hairs.
(although i'll change it if anyone feels strongly)

-garrett

-- 
garrett rooney                     Unix was not designed to stop you from 
rooneg@electricjellyfish.net       doing stupid things, because that would  
http://electricjellyfish.net/      stop you from doing clever things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.