[ls-issues?] Re: Why do commands fail when a file is unknown to svn?

----- Original Message -----
From: "Ben Reser" <ben@reser.org>
To: "C.A.T.Magic" <c.a.t.magic@gmx.at>

[...]

> > if I now get it right,
> > > svn ls
> > will access -the server- and list all files under revision control there
> > and not all files 'that exist in the working dir AND are under version
> > control'
>
> No you've got it wrong. svn ls /path/to/wc will give you the files in
> the working copy that are or are scheduled to be added to the repo.

not really (!?)
for example try renaming a folder or deleting a file,
then use svn ls -
it will present you everything that was there "at checkout time",
instead of the actual state - [ intended? ].
this gave me the impression that it was using the last
server data (but ofcourse its just using the cached data from .svn).
OK. I'll stick to using svn status and filter on the first character
meantime
- and use svn ls only for the server repository.

--
svn ls is not ducumented in
http://svnbook.red-bean.com/book.html
and svn ls --help isn't too verbose about what it really does.
--
I also had the feeling it is using the server because svn ls -R
takes -a fortune- to complete on my working dir
( with only about 1.000 files, on my 3.2Ghz/1GB box ).
it seems that svn ls is summing up all the strings in an
internal buffer and printing the whole buffer when completed,
while consuming 250Megbytes(!) of memory.
at least the huge memory consumption will be an issue on
slightly larger wc. why not print everything out immediate?
--
> > how about some extra flags for
> >   " list --version-controlled-files-in-working-dir "
> > this would then probably be somewhat similar to
> >   " status --without-the-single-characters-in-front "
> >  (ofcourse something shorter would be nice:)
>
> Totally unnecessary and ridiculously long option names.
i meant the names as an explanation, not as a suggestion.
but try --help on almost any *nix command and you will see
much longer option names. also compare the amount
of available 'switches' available to most *nix commands
( e.g. *nix> ls --help )
> It already does work this way.  Why didn't you try it before you sent
> the message?
because it also prints files that are -NOT really- in the working dir.
(for example manually deleted or not-yet checked-out files, renamed files,
renamed folders etc -- rename or delete something or try ctrl-c during
checkout -- makes everything slightly inconsistent )
why didn't -you- try it before you answered? ;-)
> > And while I may have the ear of an svn developer --
> >    svn ls -N   <--- unsupported/error (nonrecursive is default)
> >    svn ls -R
> >    svn add -N
> >    svn add -R   <--- unsupported/error (recursive is default)
[...]
> This has been explained over and over and over again.  The defaults
> exist the way they are because they are the most common use case.  Most
> people don't want a recursive list but do what a recursive add.
>
> See this thread for past discussion:
> http://marc.theaimsgroup.com/?l=subversion-dev&m=107453293614903&w=2
I'm not questioning the defaults (which are ok),
I asked why using the opposite flag results in an error.
> And would you all stop CC'ing the dev@subversion.tigris.org list with
> this chatter about how to use the software.
sorry. seems to have happened -once-.
I know, reading 'dumb users' complaints, issues and bugreports
all day long is annoying -- have to do that myself once a day.
happy coding,
:-)
======
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org