Re: Subversion 1.10 RC1?

[Daniel Shahaf]

Evgeny Kotkov wrote on Wed, Dec 06, 2017 at 00:12:55 +0300:
> Unfortunately, on Windows both `--search M*` and (quoted) `--search "M*"`
> would expand the asterisk.  While this is not the default shell behavior,
> currently it's enabled for svn and a couple of other binaries by linking
> to setargv.obj.  In turn, this probably means the command-line client
> users on Windows could get quite unexpected results when using the
> `--search ARG` syntax.

Isn't there some escaping syntax, «svn log --search "M^*"» or something along
these lines?

Re: Supporting precooked fsfs v7 and v1-v3 in the test suite (was: Re: svn commit: r1813898 [...])

[Stefan Fuhrmann]

On 27.11.2017 12:41, Evgeny Kotkov wrote:

[Changing subject, as apparently the test failures are not connected to
  the discussed fix for the rep sharing and issues #4623, #4700]

Stefan Fuhrmann  writes:


Test expectations may need to be adapted.
With v7 repos (see r1816402), I get two
test failures while v4 and v6 pass:


[...]


FAIL:  svnadmin_tests.py 12: svnadmin verify detects corruption dump can't


[...]


FAIL:  svnadmin_tests.py 24: svnadmin verify with non-UTF-8 paths


I committed two follow-ups to the addition of precooked v7 repositories
in r1816402:

 https://svn.apache.org/r1816424
 https://svn.apache.org/r1816425

The first of these follow-ups limits the mentioned svnadmin tests to only
run with precooked repositories of formats 4 and 6 — as these tests perform
a set of hardcoded manipulations, assuming that the repository does not
use logical addressing.


Thanks.


Speaking of the added precooked repositories of formats 1-3, I am not too
sure if they should be created with the 1.9 binaries, as stated in the log
message for r1816402.  I think that the actual repositories created with
older SVN versions may be different from the ones created with the
`--compatible=version=` option, and that using the latter approach may
just create a false sense of security.

Perhaps, an alternative way would be to find the 1.1 binaries, prepare the
precooked format 1 repositories using it and limit the set of precooked
repositories to v1, v4, v6 and v7.


It took some manual intervention but I was able to build 1.1
and friends on my workstation and re-created the template repos
with those. They actually are different, in particular their
fsfs.conf and the presence of some files is not the same as
with later releases.

 https://svn.apache.org/r1816944


(Also, I think that the main.py:parse_options() function may need an update
  to properly handle the added v1-v3 precooked repositories by downgrading
  the server_minor_version — as otherwise, the various test suite checks such
  as server_has_mergeinfo() won't kick in.)


As of r1816965, that's fixed.  There is still things that will
fail for v1-v3 but these should not be too hard to fix in the
near future.

-- Stefan^2.

Re: Potential regression: high server-side memory consumption during import (was: Subversion 1.10 RC1?)

[Stefan Fuhrmann]

On 05.12.2017 22:05, Evgeny Kotkov wrote:

Julian Foad  writes:


After any issues raised in this discussion are resolved, we feel we should
go ahead and produce RC1 as soon as possible.


I think that I am seeing a 1.10 regression in terms of httpd's memory
usage during large imports.

In my environment, when I `svn import` an unpacked version of Boost
(https://www.boost.org/) that consists of around 60,000 files, I see that
the memory consumption by the server process rapidly grows up to 1.5 GB.
The environment is a Windows 8.1 x64 machine with httpd 2.4.29 configured
to use short-circuit authz and HTTPS.  Apparently, this behavior is specific
to 1.10, as I cannot reproduce it with 1.9 binaries.

  (I haven't investigated the issue any further at this time, and it might as
   well be reproducible in other configurations.)


Would it be possible for you to bisect this to
find the offending revision?  My random guess
would be that in the context of mod_dav_svn, we
might use an unsuitable pool for authz caching.

-- Stefan^2.

Re: [PATCH] release.py: write-changelog function (POC)

[Johan Corveleyn]

On Tue, Dec 5, 2017 at 1:00 PM, Branko Čibej  wrote:
> On 04.12.2017 23:01, Julian Foad wrote:
>> Johan Corveleyn wrote:
>>> [...]
>>> Hm, yes, I agree with the "don't write the same thing twice". But
>>> perhaps the "general description" above the list of affected files
>>> would be a better place:
>> [...]
>>> Though, indeed, we're not required to always have a "general
>>> description", and can just start with the affected files, if the
>>> change is simple. So ... not sure.
>>>
>>> That's the thing I'm most uncertain of at the moment: how to fit this
>>> scheme precisely into our current log message style, without
>>> interfering too much, keeping them as readable as possible for human
>>> readers.
>>>
>>> Maybe a syntax with '@' would be better, like annotations in Java or
>>> doxygen. Like:
>> [...]
>>> or as a suffix:
>> [...]
>>> Just thinking out loud here ...
>> [...]> H
>>
>> Now you're over-thinking it. What you said first, what you use at
>> work, is fine. Run with it!
>
>
> IMO the important thing is to make the tagging in the log messages as
> human-friendly as possible. That's what made the contribulyzer work so
> well: there were no $[@foo;\\} syntactical quirks to remember and the
> syntax is permissive.
>
> Therefore I think stsp's suggestion of just taking the summary line in
> the log message as the CHANGES entry is more likely to produce useful
> results than any magic tagging. I don't think it's all that important to
> classify the change into user-facing, etc., at commit time. All we need,
> IMO, is a way to signal whether the change is or is not important.
>
> So I'd suggest we use stsp's proposal with a small difference: by
> default, every log message that has a summary line is important. If it's
> not, start the first line with a # to tell the script to ignore it. That
> way, it takes extra thought and effort to exclude a commit from the
> CHANGES summary, which is IMO preferable to having to put in extra
> thought and effort to have it included. It's easier to prune unnecessary
> entries from the summary than it is to dig into commit history to find
> the missing ones.

I'm not sure. I think we're very much accustomed to a certain style
for CHANGES, and another style and information-density for the summary
of commit messages. If these could converge, then sure, this could be
a good idea. If not, I think we haven't gained much (the RM would have
to rephrase them all anyway).

For example, CHANGES for 1.10 contains (just taking a couple of
entries under User-visible "Minor new features and improvements"):

* New '--file' option for several svnadmin subcommands (r1738021)
* ra_serf: Adjustments for serf versions with HTTP/2 support (r1716400)
* windows: Correctly check result from LoadLibrary() call (r1755983)
* FSFS: Open transaction's proto revision in write-only mode (r1759135)

And the corresponding lines out of "./release.py write-changelog
--pocfirstlines trunk tags/1.9.7" are (just grepping on the revision
numbers):

* Introduce `--file' option for svnadmin dump, dump-revprops, load
and (r1738021)
* Apply some minor tweaks to libsvn_ra_serf to handle some http/2
cases. (r1716400)
* Correctly check result from LoadLibrary() call: LoadLibrary()
returns NULL (r1755983)
* FSFS: Open transaction's proto revision in write-only mode.
Read/write mode (r1759135)

That last one is actually the same, nice :-).

I think these could converge, i.e. we *can* get used to write our
summaries in the CHANGES style (for instance: put the relevant
"component" in front, like "ra_serf:", "windows:", ...; and make the
first line of the summary shorter). But it'll take getting used to
:-).

Another thing is that there are a lot more commits than entries in CHANGES.
* CHANGES for 1.10 is currently 244 lines.
* output of "./release.py write-changelog --pocfirstlines trunk
tags/1.9.7" is 1633 lines.

That means we'd have to use the "#" (or other symbol) escape a lot.
That, or a lot of those commits are reverts (we'd need to handle these
well in any case), or are summarized with "(... et al)".

The flip side would be, if we could get the hang of this, we'd need no
special syntax, no duplication of "almost the same text", and our
"commit message summaries" are automatically fit for CHANGES (and it's
safer to forget to exclude a commit). Which also means an option for
"svn log" showing only the first line would be interesting, and would
approximately yield CHANGES plus the "#-escaped" summaries.

Hmmm, red pill or blue pill.

-- 
Johan