Re: svn commit: r1872919 - /subversion/trunk/subversion/tests/libsvn_subr/mergeinfo-test.c

[Daniel Shahaf]

julianf...@apache.org wrote on Fri, Jan 17, 2020 at 14:54:46 -:
> @@ -2089,18 +2130,22 @@ test_rangelist_merge_random_canonical_in
> +if (failure_mode)
>{
> -printf("testcase FAIL: %s / %s\n",
> +printf("first example of a failure mode: %s / %s\n"
> +   "  %s\n",
> rangelist_to_string(rlx, iterpool),
> +   rangelist_to_string(rly, iterpool),
> +   failure_mode);

Test programs aren't supposed to print arbitrary stuff to stdout.

Specifically, the interface between run_tests.py and the test programs
specifies¹ that test programs shall only print "PASS:" and "FAIL:" lines by
default.  We could of course extend that to support printing of new info, for
example, as "INFO:" lines.  So would it make sense to prepend "INFO:" to that
line?

Cheers,

Daniel

¹ Citation: subversion/tests/README:34

Re: [#4840] Merge assertion failure in svn_sort__array_insert

[Nathan Hartman]

On Fri, Jan 17, 2020 at 10:36 AM Daniel Shahaf  wrote:
> Julian and I discussed this on IRC today; the conclusion is:
>
> - With the behaviour of the test with seed=0 having been manually
>   reviewed, we're satisfied that the test achieves adequate coverage.
>
> - The properties that the magic numbers were chosen to satisfy will be
>   documented in code comments.
>
> - Julian has further reviewed the code, leading to, e.g., r1872919.

For convenience, a link to an archive:
https://colabti.org/irclogger/irclogger_log/svn-dev?date=2020-01-17

Thanks,
Nathan

Re: [#4840] Merge assertion failure in svn_sort__array_insert

[Daniel Shahaf]

Julian Foad wrote on Thu, 16 Jan 2020 09:18 +00:00:
> I inspected the debug prints whizzing by, and noted that it included 
> each of the different kinds of input cases I expected (e.g. empty 
> ranges, reversed ranges, duplicate ranges, overlapping ranges, etc.) and 
> that the results included examples of the failure modes I expected.
> 
> Based on that observation, I altered the parameters such as the sizes of 
> the generated revision ranges and the repetition counts, until it 
> provided good coverage without excessive repetition. I aimed for "a few" 
> (more than one, less than hundreds) of occurrences of the same failure mode.
> 
> That doesn't guarantee coverage of every possible edge case combination, 
> of course, but it gives me confidence that it's an effective test. I 
> admit it's an issue that that is not apparent to an observer. However, 
> anyone needing to debug again can enable the debug prints and see it.

Julian and I discussed this on IRC today; the conclusion is:

- With the behaviour of the test with seed=0 having been manually
  reviewed, we're satisfied that the test achieves adequate coverage.

- The properties that the magic numbers were chosen to satisfy will be
  documented in code comments.

- Julian has further reviewed the code, leading to, e.g., r1872919.

Thanks, Julian.

Daniel

Re: 20th anniversary press?

[Nathan Hartman]

On Thu, Jan 16, 2020 at 3:14 PM Doug Robinson 
wrote:

> It's super cool that Subversion's birthday is Leap Day 2000. [1]
>>
>> I think it's a great idea to celebrate with a press release.
>>
>
> There's a LinkedIn discussion group for SVN (and CVS) [3].  Perhaps
> posting there might get some testimonials?
>
> [3] https://www.linkedin.com/groups/157593/
>

Thanks for mentioning that.

Would someone who has a LinkedIn account be kind enough to post a very
polite request for testimonials there? (for our 20th anniversary press
release)

Also, would it be appropriate and acceptable to post this request to our
own users@ list?

I feel we should make the most of every marketing opportunity.

Thanks,
Nathan

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)