On Aug 11, 2005, at 7:22 AM, Alexander Thomas wrote:
> On Wed, 2005-08-10 at 15:20 -0500, Ben Collins-Sussman wrote:
>
>> Ok, time to argue about bikeshed color. After applying a tweaked
>> version of the patch and running 'svn ls -v', nearly every single
>> filename wraps off the edge of my 80-column terminal. This is not
>> good.
>>
>>
> Yes I agree is not good, not bad either.
For this project, it's bad. We have an 80-column convention not only
for our source code, but for commandline output as well. Granted,
'svn ls' cannot ever *guarantee* that it will never go beyond 80
columns, because it has no control over the length of filenames. But
we're still under an obligation to try to prevent that situation as
much possible, by providing as much space for the filename as we can.
Under that philosophy, the main goal of this feature is to make 'svn
ls -v' indicate that a file *is locked* at all, not to display all
the lock fields. ("svn info" is the best tool for showing all lock
fields.) So I think we should have exactly one new column that
indicates the presence of a remote lock: it could be a single
character, or it could be one of the svn_lock_t fields. But more
than one column is overkill; the goal is simply to let users know
that a lock exists.
>
> I think it pretty clear from 'svn help' the order of occurrence, So
> why we need to distinguish between last_author and lock_author in
> output?.
Because not everybody reads the help output. The new "lock is
present" column should stand out as something unique. For example,
seeing
398 username1 username2 216576 Apr 27 14:31 slouch.z5
... I think users will scratch their heads, wondering why the
username is being listed twice. They may not even bother to look at
'svn help ls', but just gloss over the extra information.
But if users see
398 username1 *username2 216576 Apr 27 14:31 slouch.z5
or
398 username1 * 216576 Apr 27 14:31 slouch.z5
... then it's clearer that something is "special" about that extra
column.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 11 15:12:39 2005