Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2020-01-16 10:37:05 +, Julian Foad wrote:
> Branko Čibej wrote:
> > > Why are we overthinking this?
> 
> Indeed.  There is a lot of energy going in to this thread.  It's great to
> see energy and enthusiasm, but...
> 
> I know the current algorithm is sometimes annoying.
> 
> I accept sub-optimal decisions about it have been made in the past.
> 
> Any algorithm is going to be annoying in some cases.  If we were ever to
> change the algorithm, I suggest it would make sense to copy some well known
> one (e.g. from an implementation of unix 'ls' or a git command);

Note that ls and git may be bad examples since they are both local
(well, for ls, directories can be remote such as via NFS or SSHFS,
but I don't think that it has been written primarily for such cases).
For ls, I've checked that the output is correctly aligned, even
in the case of several thousands of files followed by a file with
user/group names larger than 8 characters.

For svn, it depends whether you can accept to have all the data
before outputting anything. For me, it would be OK, even with
the -R option.

> it would not make sense to invent another one of our own. But it
> does not makes sense to change the default algorithm again at all in
> svn 1.x series. It would be resonable only as part of a complete
> redesign of the command line interface some day.
> 
> Adding caching for this particular issue is really over-kill.  Caching is
> hard to get right.  (One issue, for example, is how revision properties can
> be modified on the server, and there is so far no mechanism for efficiently
> letting clients find out about the changes. That's one form of "stale cache"
> scenario to be figured out.)

This does not really apply in the particular case of "svn ls -v" since
only some length would be cached. The user will not get "old" data.
Just possibly columns larger than needed in case some long author name
no longer exists.

> On the other hand, if we invested in caching for more general use in the
> client, and then got username length information "for free" out of that,
> that would be a different matter.

Note that caching the logs would really be useful, as this is often
very slow to get some old logs.

[...]
> On the other hand, a more general configuration scheme to be able to specify
> the output line format for each of the main svn commands would be much more
> widely useful.  It would have advantages such as being able to generate
> abbreviated outputs tailored to certain use cases (e.g. in a private repo, I
> might not care to see my username at all); or emulating (to a limited
> extent) older versions of svn for compatibility with old scripts.

This would really be great. Not to have ISO 8601 dates is also
annoying.

> From a business point of view it would be hard to justify adding that
> flexibility -- it is hard to imagine many people making much use of it.

Most tools have much flexibility (this includes ls and git). I suppose
that people use them.

Various tools use a printf-like format (e.g. Mutt, zsh).

> But the more generic it is (e.g., available for all commands the
> print lines of output, not just 'ls' or just username fields) the
> more likely it is to be found useful. As this is open source, if
> someone wants to develop that, they can.
> 
> As I think out loud further down this road, I am thinking the fields used in
> the format template string should correspond exactly to the fields available
> in the XML output, using the same names.  In fact the line format output
> should be programmatically derivable from the XML.

I agree.

> And we have recently mentioned adding other formats such as JSON,
> which may be more widely useful in today's software tooling
> ecosystem.

Except that there are more tools to parse XML than JSON.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Julian Foad]

Branko Čibej wrote:

Why are we overthinking this?


Indeed.  There is a lot of energy going in to this thread.  It's great 
to see energy and enthusiasm, but...


I know the current algorithm is sometimes annoying.

I accept sub-optimal decisions about it have been made in the past.

Any algorithm is going to be annoying in some cases.  If we were ever to 
change the algorithm, I suggest it would make sense to copy some well 
known one (e.g. from an implementation of unix 'ls' or a git command); 
it would not make sense to invent another one of our own.  But it does 
not makes sense to change the default algorithm again at all in svn 1.x 
series.  It would be resonable only as part of a complete redesign of 
the command line interface some day.


Adding caching for this particular issue is really over-kill.  Caching 
is hard to get right.  (One issue, for example, is how revision 
properties can be modified on the server, and there is so far no 
mechanism for efficiently letting clients find out about the changes. 
That's one form of "stale cache" scenario to be figured out.)


On the other hand, if we invested in caching for more general use in the 
client, and then got username length information "for free" out of that, 
that would be a different matter.


The alternative to changing the default algorithm is to add an option to 
control the output to the user's preference.  It could be something as 
specific as a setting for the column width to allow for the name column, 
or as generic as specifying an output format template string, along the 
lines of a "printf" format string.


I hate options.  At least I hate lots of tiny specific-tweak options 
like specifying the width of a particular column.  For relatively 
trivial things like this (compared with other svn problems; though I 
know it can be annoying), please, no.


On the other hand, a more general configuration scheme to be able to 
specify the output line format for each of the main svn commands would 
be much more widely useful.  It would have advantages such as being able 
to generate abbreviated outputs tailored to certain use cases (e.g. in a 
private repo, I might not care to see my username at all); or emulating 
(to a limited extent) older versions of svn for compatibility with old 
scripts.


From a business point of view it would be hard to justify adding that 
flexibility -- it is hard to imagine many people making much use of it. 
But the more generic it is (e.g., available for all commands the print 
lines of output, not just 'ls' or just username fields) the more likely 
it is to be found useful.  As this is open source, if someone wants to 
develop that, they can.


As I think out loud further down this road, I am thinking the fields 
used in the format template string should correspond exactly to the 
fields available in the XML output, using the same names.  In fact the 
line format output should be programmatically derivable from the XML. 
And we have recently mentioned adding other formats such as JSON, which 
may be more widely useful in today's software tooling ecosystem.  They 
should all be programmatically related, not implemented each according 
to its own implementor's whims.


The important point I'm trying to draw out is that we can treat 
something like as an opportunity to re-examine not just the micro scope 
(a particular column width in 'ls') but the potential for improving 
things more widely.


If the exercise leads to those sorts of improvements, +1.

If that's all too much for anyone to consider, I recommend either living 
with the current imperfect behaviour or making a private patched version 
and then offering that patch for anyone else to try, perhaps building 
support for it that way.


- Julian

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2020-01-13 16:51:25 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00:
> > Good point. I was about to say that in most cases, these commands are
> > run from a working copy. But I now think that caching should be done
> > under the user's home (just like with most applications). Under Unix,
> > this would be under "$XDG_CACHE_HOME/subversion".
> 
> When would data be evicted from the cache?

In this particular case, I wonder whether there is any reason to
evict data from the cache. And the user can still entirely remove
the cache manually if need be.

> I'd say UUID, but we don't have to decide this now.

On 2020-01-14 13:19:08 +0100, Branko Čibej wrote:
> Why are we overthinking this? This information is really not relevant
> for integration with other tools:
> 
>   * GUIs don't need it; they can always dynamically resize columns in forms.

Dynamic resize is annoying: one is reading something, but this
suddenly goes away due to a resize.

>   * The command-line doesn't (really) need it; all information,
> including untruncated commiter names, is available in --xml mode.

Yes, but this needs to add a pipe or use a different command name
(this is no way to override the "svn ls" behavior... except by
using a wrapper, attempting to parse the arguments).

BTW, if untruncated committer names are available in --xml mode, it was
not necessary to change the behavior and break the column alignment.

> Adding a layer of caching is only going to add a stale-cache problem
> that we don't have now.

What stale-cache problem?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Branko Čibej]

On 13.01.2020 17:51, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00:
>> On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
>>> Since both 'svn ls -v' and 'svn blame' can be called on a repository
>>> URL, I don't really see the point in caching the max(length(author))
>>> of the working copy.
>>>
>>> The output from a URL would still be mis-aligned. It would make the
>>> presentation inconsistent between calling it on a working copy and on
>>> a URL.
>> Good point. I was about to say that in most cases, these commands are
>> run from a working copy. But I now think that caching should be done
>> under the user's home (just like with most applications). Under Unix,
>> this would be under "$XDG_CACHE_HOME/subversion".
> When would data be evicted from the cache?
>
>> The data should be associated with the URL of the repository.
> I'd say UUID, but we don't have to decide this now.


Why are we overthinking this? This information is really not relevant
for integration with other tools:

  * GUIs don't need it; they can always dynamically resize columns in forms.
  * The command-line doesn't (really) need it; all information,
including untruncated commiter names, is available in --xml mode.


Adding a layer of caching is only going to add a stale-cache problem
that we don't have now.

-- Brane

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Vincent Lefevre wrote on Mon, 13 Jan 2020 10:26 +00:00:
> On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
> > Since both 'svn ls -v' and 'svn blame' can be called on a repository
> > URL, I don't really see the point in caching the max(length(author))
> > of the working copy.
> > 
> > The output from a URL would still be mis-aligned. It would make the
> > presentation inconsistent between calling it on a working copy and on
> > a URL.
> 
> Good point. I was about to say that in most cases, these commands are
> run from a working copy. But I now think that caching should be done
> under the user's home (just like with most applications). Under Unix,
> this would be under "$XDG_CACHE_HOME/subversion".

When would data be evicted from the cache?

> The data should be associated with the URL of the repository.

I'd say UUID, but we don't have to decide this now.

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2020-01-10 16:58:26 +0100, Johan Corveleyn wrote:
> Since both 'svn ls -v' and 'svn blame' can be called on a repository
> URL, I don't really see the point in caching the max(length(author))
> of the working copy.
> 
> The output from a URL would still be mis-aligned. It would make the
> presentation inconsistent between calling it on a working copy and on
> a URL.

Good point. I was about to say that in most cases, these commands are
run from a working copy. But I now think that caching should be done
under the user's home (just like with most applications). Under Unix,
this would be under "$XDG_CACHE_HOME/subversion".

The data should be associated with the URL of the repository.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Johan Corveleyn]

On Fri, Jan 10, 2020 at 3:28 PM Vincent Lefevre  wrote:
> On 2020-01-08 13:12:21 +, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> > > On 2020-01-07 16:10:52 +, Daniel Shahaf wrote:
> > > > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > > > On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> > > > > > Two things are not immediately clear to me:
> > > > > >
> > > > > > - This info is only needed by the cmdline client, not by other
> > > > > >   library users. This suggests the API should be generic. A
> > > > > >   per-client cache, maybe? There's already a
> > > > > >   svn_client_ctx_t::client_name so it's not unprecedented.
> > > > >
> > > > > Well, you don't know what the library users will do. Perhaps the cache
> > > > > will benefit them too. The value can be used by them or not.
> > > >
> > > > I think you've missed my point.  I'm saying we should try to design the 
> > > > cache
> > > > API in a way that will allow it to be used not only for 'svn ls -v' but 
> > > > also
> > > > for other things.  The API does not exist to serve the cmdline client; 
> > > > it
> > > > exists to serve _all_ svn clients.
> > >
> > > I entirely agree. But I'm still confused by your first sentence above
> > > "This info is only needed by the cmdline client, not by other library
> > > users." or perhaps you misplaced the "not"?
> >
> > The length of the longest author name is needed by 'svn ls -v'.
> >
> > The length of the longest author name is unlikely to be needed by
> > other consumers of the svn_client_* API.
>
> A reimplementation of "svn ls -v" or "svn blame" may find this useful
> information. Graphical clients may be interested in a cached full list
> of authors to compute the size of the corresponding column.

Since both 'svn ls -v' and 'svn blame' can be called on a repository
URL, I don't really see the point in caching the max(length(author))
of the working copy.

The output from a URL would still be mis-aligned. It would make the
presentation inconsistent between calling it on a working copy and on
a URL.

Just my 2 cents ...
-- 
Johan

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2020-01-08 13:12:21 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> > On 2020-01-07 16:10:52 +, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > > On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> > > > > Two things are not immediately clear to me:
> > > > > 
> > > > > - This info is only needed by the cmdline client, not by other
> > > > >   library users. This suggests the API should be generic. A
> > > > >   per-client cache, maybe? There's already a
> > > > >   svn_client_ctx_t::client_name so it's not unprecedented.
> > > > 
> > > > Well, you don't know what the library users will do. Perhaps the cache
> > > > will benefit them too. The value can be used by them or not.
> > > 
> > > I think you've missed my point.  I'm saying we should try to design the 
> > > cache
> > > API in a way that will allow it to be used not only for 'svn ls -v' but 
> > > also
> > > for other things.  The API does not exist to serve the cmdline client; it
> > > exists to serve _all_ svn clients.
> > 
> > I entirely agree. But I'm still confused by your first sentence above
> > "This info is only needed by the cmdline client, not by other library
> > users." or perhaps you misplaced the "not"?
> 
> The length of the longest author name is needed by 'svn ls -v'.
> 
> The length of the longest author name is unlikely to be needed by 
> other consumers of the svn_client_* API.

A reimplementation of "svn ls -v" or "svn blame" may find this useful
information. Graphical clients may be interested in a cached full list
of authors to compute the size of the corresponding column.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Vincent Lefevre wrote on Wed, Jan 08, 2020 at 10:28:01 +0100:
> On 2020-01-07 16:10:52 +, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > > On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> > > > Two things are not immediately clear to me:
> > > > 
> > > > - This info is only needed by the cmdline client, not by other
> > > >   library users. This suggests the API should be generic. A
> > > >   per-client cache, maybe? There's already a
> > > >   svn_client_ctx_t::client_name so it's not unprecedented.
> > > 
> > > Well, you don't know what the library users will do. Perhaps the cache
> > > will benefit them too. The value can be used by them or not.
> > 
> > I think you've missed my point.  I'm saying we should try to design the 
> > cache
> > API in a way that will allow it to be used not only for 'svn ls -v' but also
> > for other things.  The API does not exist to serve the cmdline client; it
> > exists to serve _all_ svn clients.
> 
> I entirely agree. But I'm still confused by your first sentence above
> "This info is only needed by the cmdline client, not by other library
> users." or perhaps you misplaced the "not"?

The length of the longest author name is needed by 'svn ls -v'.

The length of the longest author name is unlikely to be needed by 
other consumers of the svn_client_* API.

Cheers,

Daniel

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2020-01-07 16:10:52 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> > > Two things are not immediately clear to me:
> > > 
> > > - This info is only needed by the cmdline client, not by other
> > >   library users. This suggests the API should be generic. A
> > >   per-client cache, maybe? There's already a
> > >   svn_client_ctx_t::client_name so it's not unprecedented.
> > 
> > Well, you don't know what the library users will do. Perhaps the cache
> > will benefit them too. The value can be used by them or not.
> 
> I think you've missed my point.  I'm saying we should try to design the cache
> API in a way that will allow it to be used not only for 'svn ls -v' but also
> for other things.  The API does not exist to serve the cmdline client; it
> exists to serve _all_ svn clients.

I entirely agree. But I'm still confused by your first sentence above
"This info is only needed by the cmdline client, not by other library
users." or perhaps you misplaced the "not"?

> > In any case, making the information available will not hurt.
> 
> It will hurt, actually. If we add the API we'll need to support it
> until 2.0 (= indefinitely), and everyone who ever tried to write
> code to the libsvn_client interface will have another function
> docstring to read and decide they don't care about.

Yes, perhaps this will have drawbacks at the API level, but the
information can be useful for various reasons, and the library
users could just decide to use it or not.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, 07 Jan 2020 16:10 +00:00:
> Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> > On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > > > On 2019-12-21 08:09:46 +, Daniel Shahaf wrote:
> > > > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > > > There's something wrong with "svn list -v" column alignment when
> > > > > > there are author names with more than 8 characters. For instance,
> > > > > > with the gcc repository:
> > > > > > 
> > > > > > [...]
> > > > > >  279442 jozeflDec 16 12:02 libgcc/
> > > > > >  278886 jvdelisle  Dec 01 23:29 libgfortran/
> > > > > > [...]
> > > > > 
> > > > > As implemented, the width is initially 8 but as soon as a longer name 
> > > > > is seen,
> > > > > subsequent lines will be aligned with that, up to a maximum length of 
> > > > > 16.
> > > > > 
> > > > > Do you have a better algorithm to propose?
> > > > 
> > > > cache the maximum length name in the working-copy data.
> > > 
> > > Let's see.  We could cache the value in wc.db.  Running 'ls' or 'blame' 
> > > [the
> > > same considerations apply to both] would update the cache; running 
> > > 'cleanup'
> > > would purge it.
> > > 
> > > Two things are not immediately clear to me:
> > > 
> > > - This info is only needed by the cmdline client, not by other
> > >   library users. This suggests the API should be generic. A
> > >   per-client cache, maybe? There's already a
> > >   svn_client_ctx_t::client_name so it's not unprecedented.
> > 
> > Well, you don't know what the library users will do. Perhaps the cache
> > will benefit them too. The value can be used by them or not.
> 
> I think you've missed my point.  I'm saying we should try to design the cache
> API in a way that will allow it to be used not only for 'svn ls -v' but also
> for other things.  The API does not exist to serve the cmdline client; it
> exists to serve _all_ svn clients.

To clarify: I think we should try to design the API in a way that will
(1) let it be used not only for author names but also for other things,
(2) let it be used not only by the cmdline client.

I mean, we _could_ add a private API that does "SELECT change_author
FROM nodes ORDER BY strlen(change_author) DESC LIMIT 1" and have the
cmdline client use that, and maybe that's actually the right answer, but
let's at least _try_ to come up with a better / more generic design first.

Cheers,

Daniel

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Vincent Lefevre wrote on Tue, Jan 07, 2020 at 16:17:10 +0100:
> On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > > On 2019-12-21 08:09:46 +, Daniel Shahaf wrote:
> > > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > > There's something wrong with "svn list -v" column alignment when
> > > > > there are author names with more than 8 characters. For instance,
> > > > > with the gcc repository:
> > > > > 
> > > > > [...]
> > > > >  279442 jozeflDec 16 12:02 libgcc/
> > > > >  278886 jvdelisle  Dec 01 23:29 libgfortran/
> > > > > [...]
> > > > 
> > > > As implemented, the width is initially 8 but as soon as a longer name 
> > > > is seen,
> > > > subsequent lines will be aligned with that, up to a maximum length of 
> > > > 16.
> > > > 
> > > > Do you have a better algorithm to propose?
> > > 
> > > cache the maximum length name in the working-copy data.
> > 
> > Let's see.  We could cache the value in wc.db.  Running 'ls' or 'blame' [the
> > same considerations apply to both] would update the cache; running 'cleanup'
> > would purge it.
> > 
> > Two things are not immediately clear to me:
> > 
> > - This info is only needed by the cmdline client, not by other
> >   library users. This suggests the API should be generic. A
> >   per-client cache, maybe? There's already a
> >   svn_client_ctx_t::client_name so it's not unprecedented.
> 
> Well, you don't know what the library users will do. Perhaps the cache
> will benefit them too. The value can be used by them or not.

I think you've missed my point.  I'm saying we should try to design the cache
API in a way that will allow it to be used not only for 'svn ls -v' but also
for other things.  The API does not exist to serve the cmdline client; it
exists to serve _all_ svn clients.

> In any case, making the information available will not hurt.

It will hurt, actually.  If we add the API we'll need to support it until 2.0
(= indefinitely), and everyone who ever tried to write code to the
libsvn_client interface will have another function docstring to read and decide
they don't care about.

> > - What the cache keys should be. wc.db is designed to be shared
> >   among multiple WC's, so presumably the cache should be per-wcroot
> >   or possibly per-repository?
> 
> I don't understand. The wc.db file is inside the .svn directory of
> the WC. How can it be shared by multiple WC's?

It isn't, yet.  I only said it was "_designed_ to be shared among multiple
WC's".  The SQL schema is designed to allow a single wc.db to reside in, say,
$HOME/wc.db and be shared by multiple working copies: for example, in the
schema working copy files are identified by a (wc_id, local_relpath) pair.

We never got around to actually making multiple working copies share a wc.db,
but the low-level support is already there.

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2019-12-23 06:35:08 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> > On 2019-12-21 08:09:46 +, Daniel Shahaf wrote:
> > > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > > There's something wrong with "svn list -v" column alignment when
> > > > there are author names with more than 8 characters. For instance,
> > > > with the gcc repository:
> > > > 
> > > > [...]
> > > >  279442 jozeflDec 16 12:02 libgcc/
> > > >  278886 jvdelisle  Dec 01 23:29 libgfortran/
> > > > [...]
> > > 
> > > As implemented, the width is initially 8 but as soon as a longer name is 
> > > seen,
> > > subsequent lines will be aligned with that, up to a maximum length of 16.
> > > 
> > > Do you have a better algorithm to propose?
> > 
> > cache the maximum length name in the working-copy data.
> 
> Let's see.  We could cache the value in wc.db.  Running 'ls' or 'blame' [the
> same considerations apply to both] would update the cache; running 'cleanup'
> would purge it.
> 
> Two things are not immediately clear to me:
> 
> - This info is only needed by the cmdline client, not by other
>   library users. This suggests the API should be generic. A
>   per-client cache, maybe? There's already a
>   svn_client_ctx_t::client_name so it's not unprecedented.

Well, you don't know what the library users will do. Perhaps the cache
will benefit them too. The value can be used by them or not. In any
case, making the information available will not hurt.

> - What the cache keys should be. wc.db is designed to be shared
>   among multiple WC's, so presumably the cache should be per-wcroot
>   or possibly per-repository?

I don't understand. The wc.db file is inside the .svn directory of
the WC. How can it be shared by multiple WC's?

> Oh.  I missed it before, but passing -H increases the minimum width to 14.
> That's not obvious from the --help output and variable names.

But 14 is still a bit too small for me, and -H prevents the exact
sizes from being output.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Vincent Lefevre wrote on Mon, 23 Dec 2019 02:21 +00:00:
> On 2019-12-21 08:09:46 +, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > There's something wrong with "svn list -v" column alignment when
> > > there are author names with more than 8 characters. For instance,
> > > with the gcc repository:
> > > 
> > > [...]
> > >  279442 jozeflDec 16 12:02 libgcc/
> > >  278886 jvdelisle  Dec 01 23:29 libgfortran/
> > > [...]
> > 
> > As implemented, the width is initially 8 but as soon as a longer name is 
> > seen,
> > subsequent lines will be aligned with that, up to a maximum length of 16.
> > 
> > Do you have a better algorithm to propose?
> 
> cache the maximum length name in the working-copy data.

Let's see.  We could cache the value in wc.db.  Running 'ls' or 'blame' [the
same considerations apply to both] would update the cache; running 'cleanup'
would purge it.

Two things are not immediately clear to me:

- This info is only needed by the cmdline client, not by other library users.
  This suggests the API should be generic.  A per-client cache, maybe?  There's
  already a svn_client_ctx_t::client_name so it's not unprecedented.

- What the cache keys should be.  wc.db is designed to be shared among multiple
  WC's, so presumably the cache should be per-wcroot or possibly per-repository?

>

Another idea: The WC caches the "last changed author" information.  When
initializing the display width, we could initialize it as though we'd already
encountered a line with the longest "last changed author" that's cached in wc.db
(possibly for a relevant subtree).

>

(To be clear, I'm just brainstorming; I'm not going to implement either of
these ideas.  Patches welcome.)

> Make the minimum width configurable,

Currently it is only configurable by changing the constant's value and
rebuilding…

Oh.  I missed it before, but passing -H increases the minimum width to 14.
That's not obvious from the --help output and variable names.

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2019-12-23 03:21:09 +0100, Vincent Lefevre wrote:
> On 2019-12-21 08:09:46 +, Daniel Shahaf wrote:
> > Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > > There's something wrong with "svn list -v" column alignment when
> > > there are author names with more than 8 characters. For instance,
> > > with the gcc repository:
> > > 
> > > [...]
> > >  279442 jozeflDec 16 12:02 libgcc/
> > >  278886 jvdelisle  Dec 01 23:29 libgfortran/
> > > [...]
> > 
> > As implemented, the width is initially 8 but as soon as a longer name is 
> > seen,
> > subsequent lines will be aligned with that, up to a maximum length of 16.
> > 
> > Do you have a better algorithm to propose?
> 
> Make the minimum width configurable, or cache the maximum length name
> in the working-copy data.

Or wait for a fraction of second, say 0.1 s, after the first data
are available, and compute the width based on these initial data.
In most cases (e.g. when -R is not used), these data will actually
be complete, so that the output will be correct.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Vincent Lefevre]

On 2019-12-21 08:09:46 +, Daniel Shahaf wrote:
> Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> > There's something wrong with "svn list -v" column alignment when
> > there are author names with more than 8 characters. For instance,
> > with the gcc repository:
> > 
> > [...]
> >  279442 jozeflDec 16 12:02 libgcc/
> >  278886 jvdelisle  Dec 01 23:29 libgfortran/
> > [...]
> 
> As implemented, the width is initially 8 but as soon as a longer name is seen,
> subsequent lines will be aligned with that, up to a maximum length of 16.
> 
> Do you have a better algorithm to propose?

Make the minimum width configurable, or cache the maximum length name
in the working-copy data.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "svn list -v" column alignment issue

[Branko Čibej]

On 21.12.2019 00:09, Vincent Lefevre wrote:
> Hi,
>
> There's something wrong with "svn list -v" column alignment when
> there are author names with more than 8 characters. For instance,
> with the gcc repository:
>
> [...]
>  279442 jozeflDec 16 12:02 libgcc/
>  278886 jvdelisle  Dec 01 23:29 libgfortran/
> [...]

This is by design, it was a change made in 1.12.

https://subversion.apache.org/docs/release-notes/1.12.html#client-server-improvements

Yes, we realize that this makes simple output parsing harder, but the
alternative -- truncating author names at 8 characters -- was considered
worse.

-- Brane

Re: "svn list -v" column alignment issue

[Daniel Shahaf]

Vincent Lefevre wrote on Sat, Dec 21, 2019 at 00:09:09 +0100:
> There's something wrong with "svn list -v" column alignment when
> there are author names with more than 8 characters. For instance,
> with the gcc repository:
> 
> [...]
>  279442 jozeflDec 16 12:02 libgcc/
>  278886 jvdelisle  Dec 01 23:29 libgfortran/
> [...]

As implemented, the width is initially 8 but as soon as a longer name is seen,
subsequent lines will be aligned with that, up to a maximum length of 16.

Do you have a better algorithm to propose?

"svn list -v" column alignment issue

[Vincent Lefevre]

Hi,

There's something wrong with "svn list -v" column alignment when
there are author names with more than 8 characters. For instance,
with the gcc repository:

[...]
 279442 jozeflDec 16 12:02 libgcc/
 278886 jvdelisle  Dec 01 23:29 libgfortran/
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)