Karl Fogel wrote:
Julian Foad julianfoad@btopenworld.com writes:
svn status has a quirk: --verbose not only makes it display more
information about each file, but also changes the set of files of
which the status is shown, by recursing one level into any named
directories. I feel non-orthogonal behaviour like this will be a
nuisance in the long run, making it harder to write scripts that use
svn.
Only one level, or N levels (that is, all the way down?)
Only one level.
That is really weird. It's descending N levels for me (where N is as
deep as possible), which is the expected behavior. I'm recompiling
HEAD right now to make sure that's still true.
Can you post an exact reproduction recipe, including the repository
and the full output and everything? We should figure out why this is
happening for you.
Apologies: I've been confusing and confused and misleading and misled
(not by you; by my haste and inexperience with svn.). The effect that I
was trying to report is real, but I got it all mixed up. Also the
directory I used for an example only had one level of subdirectories
(apart from .svn directories) and I was using an old version of
Subversion that displayed _ characters in its status output, both of
which added confusion. I've got the latest now.
On re-evaluation, my quirk is mainly due to the difference between
handling explicit arguments and handling the results of an internal
expansion of a directory.
It is with no recursion and a wild-card argument (e.g. svn status -N
build/*) that we get this single-level expansion (rather than no
expansion which is what I expected). A directory specified as an
argument (or the implicit . which is assumed when no arguments are
given) appears to be expanded to the directory itself plus all the
non-ignored files and subdirectories within it. Those subdirectories
are not expanded if -N is given. So svn status -N shows the status
of each subdirectory without its contained files, and yet it is
impossible to request the status of a particular subdirectory without
its contained files. I feel a directory argument should be treated as
just the directory or as a list of files in that directory, but not
both. The current behaviour is good for simple user queries with
perhaps one argument, but does not generalise well (and isn't described
in the Definitive Guide).
The --verbose option does not affect the recursion level. It does
affect whether a status line is displayed for an unchanged file, as well
as printing extra columns of information, but this is not so bad.
Example:
Given that it does expand directory arguments, I expected svn status -N
build/ and svn status -N build/* to do the same, but found that there
are several differences. The latter expands one more level (last two
lines in the example output below). The latter includes files whose
names match the ignore list (*.pyc). The latter lists files that have
not changed as well as those that have.
julianfoad@linux:~/src/subversion svn status -N build/
? build/ABCDE
A build/A_NEW_FILE
julianfoad@linux:~/src/subversion svn status -N build/*
? build/ABCDE
A build/A_NEW_FILE
build/PrintPath
build/buildcheck.sh
build/gen_base.py
? build/gen_base.pyc
build/gen_make.py
? build/gen_make.pyc
build/getversion.py
? build/getversion.pyc
build/pycheck.py
build/run_tests.py
? build/win32/ABCDE
A build/win32/A_NEW_FILE
julianfoad@linux:~/src/subversion
I hope this is a little clearer and more accurate.
My feeling is that it would be best to treat the result of an internal
directory expansion the same way as the result of a shell wildcard, and
to apply the rules for ignored files, unchanged files, unknown files,
etc. equally to both. The user should give --quiet if he does not
want to see unknown files, --no-ignores if he does want to see
normally-ignored files, etc.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:18:47 2006