[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [ENHANCEMENT/BUG] svn list --verbose should not cut the author in the output

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-01-14 19:18:55 CET

Brian W. Fitzpatrick wrote:
> On Fri, 2005-01-14 at 05:07, Julian Foad wrote:
>>What is the bug that you see? What do you see as a suitable "fix"?
> That it's not the same width as it is in 'svn status' output.

Oh, I see. I suppose we could fix/change that. I thought the bug we were
talking about was that long user names were cut off.

It is not just "svn list" and "svn status" that are inconsistent, and not just
in width and truncation of user names.

             name revision date
svn list 8 7+ 12
svn status 12+ 6+
svn blame 10+ 6+ 44
   ["+" means "or more; not truncated"]

If we do something about name width, we should probably do something about
revision number width and date width at the same time:

"svn blame" currently uses an in-between field width of 10 characters, but
(like "status") does not truncate longer names, which makes it unparseable
anyway if names longer than 10 characters contain spaces.

In "svn status" we can and should increase the revision number width compatibly
to 7 or 8 by extending into spaces that already exist to the left of it. Note
that APR is already using 6-digit Subversion revision numbers.

It would seem appropriate for "blame" to use the same abbreviated date format
that is used by "list".

So, it looks some rationalisation of field widths and truncation is in order.
Either a few tweaks, in which case we might try to get away with claiming they
are bug fixes*, or a clean sweep that brings them all into line with each
other, probably only if some option is set.

Regardless of any "--xml" option that may get implemented soon, I'd be
moderately keen on sorting this out too.

- Julian

* Well, they are bugs, but design bugs that have been out in the field for a
while now, and we can't necessarily get away with just fixing them.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 14 19:26:18 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.