subversion

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

Changeset 1865934 is being indexed.

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/changelist_tests.py

(diff_with_changelists_subdir): New test.

(test_list): Run it.

Clarify LTS versus regular releases.

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

* 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

copy.

* subversion/libsvn_subr/sqlite3wrapper.c

(): Define SQLITE_OMIT_WAL.

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.

See https://sqlite.org/compile.html#recommended_compile_time_options

* subversion/libsvn_subr/sqlite3wrapper.c

(): Define SQLITE_DEFAULT_MEMSTATUS=0.

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

looping.

* 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_}visualsvn.com

* 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.
    • ?
    /site/publish/security/CVE-2018-11782-advisory.txt.asc
    • ?
    /site/publish/security/CVE-2019-0203-advisory.txt.asc
Remove a step for updating the 'upcoming changes' branch for a new minor release.

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

https://issues.apache.org/jira/browse/SVN-4823 "site: upcoming.py script

should automatically show changes for the latest stable branch".

* STATUS: Nominate r1864440.

* STATUS: Nominate r1864440.

Fix 'svn patch' setting UNIX permissions to 0600 on patched files with props.

* subversion/libsvn_client/patch.c

(init_patch_target): Use the working copy's own temp directory to store

temporary files for patching, instead of using the system-wide temp dir.

With a system-wide dir, permission paranoia in svn_io_open_unique_file3()

may kick in and result in patched files with permissions not matching the

umask. Generally, any temp files that may end up as user-visible files

in the working copy should be created in the working copy's temp dir.

Reported by: Doug Robinson at wandisco com

* upcoming.part.html: Automatically regenerated
* publish/.message-ids.tsv: Automatically regenerated.
site: Auto-update the link the the current release's STATUS file to always

point to the current stable branch.

* publish/docs/release-notes/index.html

(#upcoming-patch-release): Move a sentence from here..

* publish/upcoming.part.html: .. to here, which is automatically generated ..

* tools/generate-upcoming-changes-log.sh: .. here.

* tools/upcoming.py

(Version.__str__): New.

(get_reference_version): Add comment.

* upcoming.part.html: Automatically regenerated
site: tools/upcoming.py: Remove the last remnant of working copy usage: use of

the short URL syntax.

For SVN-4823.

* site/tools/upcoming.py:

(REPOS_ROOT_URL): New.

(copyfrom_revision_of_previous_tag_of_this_stable_branch):

Don't use the short URL syntax.

(get_merges_for_range): Change argument type.

(main): Update caller.

* upcoming.part.html: Automatically regenerated
site: upcoming.py: When cwd is not a stable branch working copy root, show

changes of the newest branch.

Fixes SVN-4823.

* site/tools/upcoming.py

(__doc__): Expand.

(get_reference_version__from_working_copy): Add TODO.

(get_reference_version__latest_stable_release): New.

(get_reference_version): New.

(main): Update caller.

site: upcoming.py: Continue removing uses of the cwd.

No functional change.

* site/tools/upcoming.py

(relative_url): Remove.

(get_merges_for_range): Change signature.

Stop calling relative_url(), which, incidentally, removes a fork() from

each iteration of the loop.

(main): Instead of calling relative_url(), just compute the URL directly.