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

On Fri, Mar 05, 2004 at 02:54:04AM +0100, C.A.T.Magic wrote:
> > 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.

Okay I got it wrong. I could have sworn it worked like how I explained
above. I was working on a script and thought I'd tested this and this
is how it behaved.

> 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.

Yup it does.

> 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.

Actually look at the help for it, it seems pretty clear that this is how
it behaves:

  List each TARGET file and the contents of each TARGET directory as
  they exist in the repository. If TARGET is a working copy path, the
  corresponding repository URL will be used.

> 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?

Yup it's hitting the repository.

> 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 )

Just becuase other apps have choosen bad options doesn't mean we should.

The better way to do this is to specify the revision. E.G. a -r WORKING
or -r WORK to get the working copies list. But svn_client_ls doesn't
even support this yet. So this might be something we could do in 1.1.0.

You can get the info from stat (for now) by doing:
svn stat -v | cut -b 41-

> why didn't -you- try it before you answered? ;-)

I thought I had earlier this week. My mistake.

> I'm not questioning the defaults (which are ok),
> I asked why using the opposite flag results in an error.

I belive that was part of the complaint in the thread I linked to and
was discussed.

> > 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-.

Uhh no. There were a number of messages on this thread that ended up on
the dev list. 10 messages to be exact:
http://marc.theaimsgroup.com/?t=107841914500007&r=1&w=2

> I know, reading 'dumb users' complaints, issues and bugreports
> all day long is annoying -- have to do that myself once a day.

I don't mind the initial discussion. But the discussion strayed far
from the purpose of the dev list.

-- 
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org