Re: Miscellaneous bugs

Julian Foad wrote:
> I would like to mention a few items from my private bug list.
...

Here is the status of each item.

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

Filed as enhancement issue #1547: '"svn proplist --quiet" should suppress "Properties on 'FILE':" messages'.

> "svn status" output is now unsorted (now that it is streamy). Needs to
> be sorted, for sanity.

### "Needs to" was too strong. Will file an enhancement issue.

> "svn proplist ." displays the directory as "''"; should be "'.'". The
> same occurs in other situations too, I think. "svn propedit" was fixed
> in r7097.

Filed as enhancement issue #1548: 'Display current dir as "." rather than empty string'.
(It could well be considered a "defect".)

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

Explained away (behaviour is correct), by C-Mike Pilato.

> "svn status -v scheduled-add-dir" shows children, but "-uv" does not.

Fixed in r7364, by C-Mike Pilato.

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

Filed as enhancement issue #1549: 'Feedback from "cleanup" and "revert"'.

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

and

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

These two are pretty much the same, I think. Filed as defect issue #1550: '"svn log" with multiple local targets is broken'.

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

Filed as enhancement issue #1551: '"svn log" handles unversioned files poorly'.

> An empty log message (-m "") is converted to a single empty line.

### Unresolved.

> A repos-to-WC copy doesn't report a scheduled add ("A file"),
> whereas a WC-to-WC copy does.

Filed as defect issue #1552: 'Inconsistency copying files to WC'.

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

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 14 02:17:27 2003