Julian Foad <julianfoad@btopenworld.com> writes:
> "svn proplist": It would be useful to be able to suppress the
> "Properties on 'FILE':" lines, and "-q" might be an appropriate way to
> request that: it would match the description "print as little as
> possible". "svn proplist -q" currently suppresses "entry not found"
> warnings, but (a) those go to stderr so they are easy to suppress
> anyway, and (b) this could be better handled by making use of the
> "ignores" list.
No opinion on whether the feature is nice, but if we decide it is
nice, +1 on invoking it via -q.
> "svn status" output is now unsorted (now that it is streamy). Needs
> to be sorted, for sanity.
To have both streaminess and sortedness is hard. Just ask CMike :-).
> "svn proplist ." displays the directory as "''"; should be "'.'". The
> same occurs in other situations too, I think. "svn propedit" was
> fixed in r7097.
Totally agree -- this is just a bug.
> "svn status -u gone-dir" shows children of gone-dir as normal. They
> should have "!" status. (gone-dir exists in repository but has been
> deleted from the disk.)
Agree, yup.
> "svn status -v scheduled-add-dir" shows children, but "-uv" does not.
Hmmm. That sounds inconsistent :-).
> "svn cleanup" and "svn revert" ought to say whether they found
> anything to do, otherwise the user doesn't learn the circumstances in
> which it is needed, or thinks the action has been performed when in
> fact the wrong file was specified. In particular, it should say if it
> found nothing to do, as this is sort of an error: the user thought a
> cleanup/revert was needed, but the software disagrees.
That's a good idea, yes.
> "svn log f f2" (where f and f2 are local files) shows the log messages
> for f, followed by those for f2, not merged. (But "svn log
> file://`pwd`/repos f f2" merges the logs correctly.)
Hmmm... Is this a regression? Mike?
> "svn log . f" in a repos-root WC shows the history of "." from 1 to
> its BASE followed by the history of "." (not "f") from 1 to f's BASE.
> "svn log a b" fails if "a" did not exist in the revision that is "b"'s
> working revision.
Blecch.
Are there any open issues on these log buglets?
> "svn log": the "Skipped <filename>" output is poor. If the file name
> is in svn:ignores it should silently ignore it instead, otherwise it
> should be an error. If this message is to be printed, it should say
> why the file was skipped, and it should go to stderr, in the same way
> the "proplist" handles such warnings.
That makes sense to me, yah.
> An empty log message (-m "") is converted to a single empty line.
Not in the repository, I think (?). 'svn log' adds a newline to every
log message when it prints it out, though, right?
> A repos-to-WC copy doesn't report a scheduled add ("A file"), whereas
> a WC-to-WC copy does.
It just doesn't report it, but still _does_ the scheduling, right?
(Agree it's a bug even so.)
> After a straight WC-to-WC copy of a file (not a dir), "svn info" shows
> a wrong base "Revision:" (it should be the same as for the source, or
> unknown as in "svn status -v"), and "svn status -v" shows unknown
> last-commit revision and author. For both files and dirs, "svn status
> -v" shows unknown base revision.
True:
$ svn cp README x
A x
$ svn st -v README x
7352 7182 jerenkrantz README
A + - ? ? x
$
I'm not sure what the right behavior is, though. The copy hasn't been
committed yet, after all...
_Whew_. Julian, you're amazing. I guess we'll need issues where we
don't have them for these (except those which are so quick to fix that
you don't want to bother with an issue).
Thanks for taking the time to write this mail!
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 8 21:30:27 2003