Greg Hudson <ghudson@MIT.EDU> writes:
> Is there a way to use "svn ls" to simply display a list of the
> directory entries at a given Subversion URL? This is what scripts
> need, after all.
And scripts can't parse the current, regularized output? :-)
> I feel like, having overridden Greg Stein's objection that this isn't
> core Subversion functionality, we have gone off into the land of
> fluffy features which look cool but aren't really necessary or even
> all that useful.
How is it any less useful than 'svn st -v'? People aren't interested
in the last changed revision/date/author? Or rather, they *are*
interested in seeing the information locally with 'st -v', but you're
saying that they *aren't* interested in seeing it remotely? I'm not
following your line of thought.
> I do think "svn ls" is core functionality, but that core function is
> to get a list of the directory entries, not to display them in a
> pretty table along with other information about them.
'svn ls' does a PROPFIND of depth 1 on a directory, and that's how it
gets back the list of children. Certainly, it could request only the
node-kind property (instead of <allprops/>, as it does now), but that
wouldn't save any extra network turnarounds. There's essentially no
difference. We're not doing any extra labor to retrieve extra
"fluffy" information.
Sorry to sound defensive. :-) I'm actually kind of -0 on 'svn ls'
existing at all once ViewSVN comes around. The only reason I created
it at all is because other dav clients (nautilus, webfolders, cadaver)
are unable to examine earlier revisions. (And the URL for viewing
older revs in your web-browser is non-public.)
But as long as 'svn ls' exists, why hold back information when we
essentially get it for free?
I dunno, maybe it's just a matter of our printing function. Maybe the
default behavior should be to print dirent names, and nothing more.
Maybe 'svn ls -v' should show the long-form listing. Then 'svn ls'
would be more consistent with 'svn status', at least in regard to
verbosity.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 29 17:55:39 2002