Checkout Tools
  • last updated 7 hours ago
Constraints: committers
Constraints: files
Constraints: dates

Changeset 1866117 is being indexed.

Publish some info on how we handle security issues.

Moved from:

* publish/docs/community-guide/issues.part.html

(#security): Point to information. Add sub-headings.

* publish/docs/community-guide/how-to-roll-releases-in-private.txt

New, extracted from the README.

* STATUS: Declare 1.11.x as 'CLOSED'.
* STATUS: Cast some votes.
* STATUS: Cast some votes.
* STATUS: Cast some votes.
* subversion/svnserve/serve.c

(construct_server_baton): Report some errors that we previously ignored.

* notes/commit-access-templates/full-committer.tmpl:

Almost revert r1866031, leaving just the http:// -> https:// change.

Update URLs in the commit access invitation templates.
* subversion/libsvn_fs_fs/verify.c (compare_p2l_to_rev):

Fix format string that was broken on 32-bit platforms.

Follow-up to r1865929: Change test to XFail, adding issue number.
Follow-up to r1865929: Restore Windows compatibility in test.
Add a test for issue #4826, diff repos-wc non-infinite depth uses wrong depth.
Fix issue #4822, "svn diff --changelist ARG" broken in subdirectories.

A follow-up to r1835234.

* subversion/libsvn_wc/diff_local.c

(svn_wc__diff7): Pass the correct anchor dir to the changelist filter.

* subversion/tests/cmdline/

(diff_with_changelists_subdir): New test.

(test_list): Run it.

Clarify LTS versus regular releases.

Suggested by: Thomas Singer <thomas.singer{_AT_}>

* download.html

Add a notice of latest LTS release after notice of latest regular release.

(#recommended-release): Change the title to "Latest regular release".

State the support period.

(#supported-releases): Change the title to "LTS releases".

State the support period.

Say "1.10 LTS" instead of just "1.10", and for 1.9, everywhere.

* index.html, news.html: remove incorrect anchors in links to download page in recent news items. Better with no anchor at all.
* site-nav.html (site-nav-menu): Remove currently unnecessary '?update=...' parameter from download link.
When compiling SQLite, enable the SQLITE_OMIT_WAL compile-time option.

We don't use WAL (write-ahead logging) feature of SQLite, but just keeping it

enabled has a visible I/O performance penalty, because SQLite has to check if

the write-ahead log file is present on disk. In a couple of my experiments,

disabling this feature resulted in a ~10% faster `svn st` on a large working


* subversion/libsvn_subr/sqlite3wrapper.c


When compiling SQLite, set the SQLITE_DEFAULT_MEMSTATUS=0 compile-time option.

This is the recommended option that is not enabled by default. Setting it to

zero avoids using a mutex (and thus suffering a performance penalty) during

every sqlite3_malloc() call, where this mutex is used to properly update the

allocations stats. We don't use sqlite3_status(), so set this option to zero.


* subversion/libsvn_subr/sqlite3wrapper.c


Win32: fix an incorrect error status being propagated to the caller in case

where we fail to stat the destination path while being in the middle of a

failed rename.

So, if we fail to stat the destination in the middle of such rename, propagate

the *original* error. Because overriding the original error with the new one

loses information about the actual cause of failure and may even confuse some

of the callers, who for instance attempt to recover in case of an EACCES,

since they may not be receiving that error at all.

(This is the behavior we had for a long time, even before r1865518, but now

seems to be an appropriate moment to fix that)

* subversion/libsvn_subr/io.c

(win32_file_rename): Use a separate `stat_err` for the case of the failed

GetFileAttributes() call. If we failed to stat the file, return the

original `err` status to the caller.

* subversion/libsvn_subr/io.c

(win32_file_rename): Rename `status` to `err`. This lays the groundwork for

fixing the incorrect error status being propagated to the caller in case

where we fail to stat the destination path while being in the middle of

a failed rename.

Win32: prevent svn_io_file_rename2() from spinning in the retry loop in a

racy case where the rename function clears the read-only attribute from the

destination file, but another thread or process is quick enough to set it

back before the original rename function has a chance to proceed.

Despite sounding like an uncommon case, this may happen when the API is

being used to atomically update the file contents while also altering its

read-only attribute (and where such updates can occur in parallel).

Fix this by including the call that clears the read-only attribute on the

destination into the retry loop instead of calling it only once before


* subversion/libsvn_subr/io.c

(win32_file_rename): Handle EACCES/EEXIST and attempt to clear the

destination read-only attribute if it's there.

(svn_io_file_rename2): Don't call svn_io_set_file_read_write() in the

Win32-specific portion of this function, since clearing the read-only

attribute is now a part of the win32_file_rename() function.

* STATUS: Nominate r1865266.

* STATUS: Nominate r1865266.

* STATUS: Nominate r1865266.

* subversion/mod_dav_svn/repos.c

(get_resource): Following up on r1850651: Set cleanup handler for

FS warning logging regardless of presence of R->USER.

Patch by: sergey.raevskiy{_AT_}

* upcoming.part.html: Automatically regenerated
Supported releases: Remove 'support period' column.

The info in it was simply wrong. Rather than correcting it, remove it as

correct and clearer details are already stated on the linked 'release planning' page.

Add recent CVEs to the list, and add my signature on their advisories.
    • ?
    • ?
Remove a step for updating the 'upcoming changes' branch for a new minor release.

Reverts r1864042, as it is now done a different way: "site: script

should automatically show changes for the latest stable branch".

* STATUS: Nominate r1864440.