Re: 20th anniversary press?

[Doug Robinson]

Folks:

On Mon, Jan 6, 2020 at 9:21 AM Nathan Hartman 
wrote:

> Daniel Shahaf  wrote:
> >
> > We're coming up on the 20th anniversary of the first commit to
> > Subversion's CVS repository:
> >
> > [[[
> > % svn log ^/subversion -r 0:HEAD -l 3 | vipe
> > 
> > r836421 | kfogel | 2000-02-29 20:32:07 -0600 (Tue, 29 Feb 2000) | 2 lines
> > Changed paths:
> > A /subversion/trunk/src
> > A /subversion/trunk/src/LICENSE
> >
> > initial checkin
> >
> > 
> > % ]]]
> >
> > Sounds like an excuse to do a press release?  Or something to mention in
> > the announcement of 1.14.0-LTS, at least?
>
>
> 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/

Cheers.

Doug


> [1] That day is cool for a variety of reasons. It's the year 2000. It
> has a leap day, contrary to most years divisible by 100 (because it's
> also divisible by 400 [2]). And it's the birthday of the best version
> control system ever!
>
> [2] https://www.timeanddate.com/date/leapyear.html
>
> Nathan
>


-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The *LiveData* Company
*Find out more 
*wandisco.com *



 



THIS MESSAGE AND ANY ATTACHMENTS 
ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED
*


If this message was 
misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not 
waive any confidentiality or privilege. If you are not the intended 
recipient, please notify us immediately and destroy the message without 
disclosing its contents to anyone. Any distribution, use or copying of this 
email or the information it contains by other than an intended recipient is 
unauthorized. The views and opinions expressed in this email message are 
the author's own and may not reflect the views and opinions of WANdisco, 
unless the author is authorized by WANdisco to express such views or 
opinions on its behalf. All email sent to or from this address is subject 
to electronic storage and review by WANdisco. Although WANdisco operates 
anti-virus programs, it does not accept responsibility for any damage 
whatsoever caused by viruses being passed.

Re: 20th anniversary press?

[Nathan Hartman]

On Thu, Jan 16, 2020 at 5:05 AM Markus Schaber 
wrote:

> maybe we’re not „high profile“ enough as we’re in a pretty niche market,
> but I talked to our marketing department and we could provide a
> testimonial. We’re using SVN both as source control system for most of our
> product developments, as well as part of one of our products (CODESYS SVN)
> which connects the CODESYS IDE to SVN repositories.
>

Hello Markus,

Thank you for your message. Yes, we'll appreciate very much if you could
provide a testimonial!

Best regards,
Nathan

Re: [#4840] Merge assertion failure in svn_sort__array_insert

[Julian Foad]

Daniel Shahaf wrote:

PRNG makes the test code harder to read and to maintain, makes it
more difficult to diagnose FAILs, and increases the risk of a bug


PRNG use makes for reasonably compact and readable test generation, and 
totally easy enough to reproduce and diagnose failures, IMO.


On the contrary, if we use static sets of cases or cases generated by 
simpler combinations of static sets of partial inputs, then it will be 
harder to read and understand whether the coverage is complete enough, 
thus increasing the risk of a bug (omission) in the tests.


- Julian

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

AW: 20th anniversary press?

[Markus Schaber]

Hi,

maybe we’re not „high profile“ enough as we’re in a pretty niche market, but I 
talked to our marketing department and we could provide a testimonial. We’re 
using SVN both as source control system for most of our product developments, 
as well as part of one of our products (CODESYS SVN) which connects the CODESYS 
IDE to SVN repositories.


Mit freundlichen Grüßen / Best regards

Markus Schaber

CODESYS Group
We software Automation.

CODESYS Development GmbH
A member of the CODESYS Group

Dipl.-Inf. Markus Schaber | Team Leader Automation Server
Tobias-Dannheimer-Str. 5 | 87439 Kempten | Germany
Tel. +49-831-54031-979
m.scha...@codesys.com | 
codesys.com

CODESYS Store: store.codesys.com
CODESYS Forum: forum.codesys.com
CODESYS Online Help: help.codesys.com

Geschäftsführer / CEOs: Dipl.-Inf. Dieter Hess, Dipl.-Inf. Manfred Werner
Handelsregister / Trade register: Kempten HRB 13379 | USt-IDNr. / Tax ID No.: 
DE 307355786

Diese E-Mail enthält möglicherweise vertrauliche und/oder rechtlich geschützte 
Informationen. Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den 
Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht 
gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient or have received
this e-mail in error, please notify the sender immediately and destroy this 
e-mail. Any unauthorized copying, disclosure
or distribution of the material in this e-mail is strictly forbidden.
Von: Nathan Hartman 
Gesendet: Freitag, 10. Januar 2020 15:38
An: Daniel Shahaf 
Cc: Subversion Development 
Betreff: Re: 20th anniversary press?

On Thu, Jan 9, 2020 at 2:28 PM Nathan Hartman 
mailto:hartman.nat...@gmail.com>> wrote:
On Thu, Jan 9, 2020 at 9:00 AM Daniel Shahaf 
mailto:d...@daniel.shahaf.name>> wrote:
Nathan Hartman wrote on Mon, Jan 06, 2020 at 09:21:33 -0500:
> Daniel Shahaf mailto:d...@daniel.shahaf.name>> wrote:
> >
> > We're coming up on the 20th anniversary of the first commit to
> > Subversion's CVS repository:
> >
> > [[[
> > % svn log ^/subversion -r 0:HEAD -l 3 | vipe
> > 
> > r836421 | kfogel | 2000-02-29 20:32:07 -0600 (Tue, 29 Feb 2000) | 2 lines
> > Changed paths:
> > A /subversion/trunk/src
> > A /subversion/trunk/src/LICENSE
> >
> > initial checkin
> >
> > 
> > % ]]]
> >
> > Sounds like an excuse to do a press release?  Or something to mention in
> > the announcement of 1.14.0-LTS, at least?
>
>
> 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.
>
> Let me know how I can help.

Would you like to liaise with Sally / press@ about this?

Sure. I'll be happy to.

According to Sally, for the press release to be meaningful, we should secure 
some testimonials from highly-visible users, preferably corporate. Apparently 
the first question the media asks is "who uses you."

It's up to us to secure those testimonials. This is pretty important. The 
biggest thing we can do to gain more help around here is to attract more 
interest and awareness.

We have corporate (and even government) customers who have posted questions to 
users@. I propose to ask there. I'm asking here first: Please ask (very nicely) 
any contacts you may have.

Thanks,
Nathan

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: [#4840] Merge assertion failure in svn_sort__array_insert

[Julian Foad]

Nathan Hartman wrote:

On Wed, Jan 8, 2020 at 9:24 AM Daniel Shahaf  wrote:
> Julian Foad wrote on Wed, Jan 08, 2020 at 10:14:42 +:
> > The suggestion was that we should prefer the regression test suite to be
> > deterministic, [...]
> But unlike nearly all of the test suite, we don't actually know what the
> sequence of inputs _is_, 


When developing/debugging, I made the test print each set of inputs, 
sometimes for every test case and sometimes just when a case failed. 
Some of that debug print code is still there, commented out.



> and we have no reason to believe it provides good
> coverage of edge cases and rare combinations of inputs. For all we know, the
> 9 iterations could all be testing the exact same, most common codepath 
over
> and over again.


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.



My earlier thinking (though I didn't spell it out) was to move the
PRNG code to a separate program, use it to generate a self-documenting
C array of unique test cases [...] If we discover new failing inputs in the
future, they can be added to the test suite. Then there is no guessing
about what inputs are being tested.


Capturing and storing generated cases into a fixed explicit could make 
some tasks slightly easier, perhaps tasks such as reaching the required 
state in a debugger, or extracting a particular case into a separate test.


What cases would you extract?  One example of each currently known 
failure mode (and success mode) is probably useful; that's a start.  I 
already made a separate test case for one failure mode, and it would be 
reasonable to do so for the others.


But what about capturing a sufficient set of input combinations that 
should be tested because they *might* in future result in different 
behaviours?  That's hard.  We can try to guess some cases that look like 
they would be worth testing, which is what we do when writing 
traditional fixed tests.  But the idea of "random" input generation is 
to overcome the tendency to fail to guess in advance all the 
combinations that might reveal a problem.  Pseudo-random inputs are good 
at that.


A good, dedicated random-testing infrastructure would make it easy to 
generate a set of fixed tests based on observing random testing combined 
with, say, code coverage information.  If we had this test 
infrastructure, sure, but if we don't, I'm not seeing why doing that 
extraction and analysis manually would be worth the effort.


The point is, we get a wide coverage of input combinations.  The 
coverage is neither theoretically nor empirically proven to be complete, 
but I demonstrated it is wide enough to be useful.



> Using a PRNG makes the test code harder to read and to maintain, makes it
> more difficult to diagnose FAILs, and increases the risk of a bug in the test
> code. What benefits are we getting that offset these risks and costs?
> 
> The way in which the PRNG algorithm is used is outside the PRNG's API promises.

> PRNG's make *no* promises on their outputs when used with a fixed seed. In
> light of this, what reason do we have to believe that the test achieves good 
coverage?


Used for test case generation, the PRNG only needs to generate a (fixed) 
sequence of numbers that with no significant correlation to the pattern 
of usage in generating test cases.  We could reasonably call it a 
"useful sequence generator" instead of "PRNG", to remove the stigma 
attached to falling short of strong randomness guarantees.


It sounds like you feel there should be a much higher quality of 
randomness.  I addressed coverage above.



> It's not necessary to use a PRNG to test a large/diverse set of inputs. You
> can achieve with plain old combinatorics (e.g., define 300 rangelist variables
> and test various combinations of them). I'd actually expect that to have
> better coverage than a PRNG with a fixed seed.


I'd be mildly interested to see the result of that analysis.  In 
practice, however, what we have now is good enough.



In other words, replace the PRNG and leave all else as-is.
Generating all permutations when picking 2 items is easy:


I don't mind if someone wants to write the test code to generate