On Thu, 17 Sept 2026 at 21:59, Daniel Sahlberg <[email protected]>
wrote:
> Thanks for the comments and fixes. A few comments below - rest LGTM!
>
>
>
> Den tis 15 sep. 2026 kl 01:34 skrev Pavel Lyalyakin <
> [email protected]>:
>
>> On Sun, 13 Sept 2026 at 23:09, Daniel Sahlberg <
>> [email protected]> wrote:
>>
>>> Den fre 11 sep. 2026 kl 23:52 skrev Pavel Lyalyakin via dev <
>>> [email protected]>:
>>>
>>>> Hello,
>>>>
>>>> I'm working on the INSTALL file, aiming to bring it up to date with the
>>>> current state of Subversion and resolve the issues that accumulated over
>>>> the decades since the file was introduced (and it's been there since the
>>>> very birth of SVN). This is still a work in progress, but I believe the
>>>> current state in trunk is a substantial improvement over the INSTALL file
>>>> in the 1.15.x branch. Any feedback would be greatly appreciated!
>>>>
>>>> The pending INSTALL changes in trunk have been nominated for backport
>>>> to 1.15.x in the "INSTALL: Corrections and cleanups" group. However, it
>>>> appears that documentation changes typically don't need a formal voting
>>>> process and don't restart the soak period when backported[1]. If that's
>>>> true then I think that it makes sense to confirm that changes to INSTALL
>>>> fall into the documentation category and let future INSTALL changes be
>>>> backported without voting.
>>>>
>>>> Please let me know what you think. Thank you!
>>>>
>>>> [1]:
>>>> https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization-backportable-changes
>>>>
>>>> --
>>>> With best regards,
>>>> Pavel Lyalyakin
>>>> VisualSVN Team
>>>>
>>>
>>> Hi Pavel!
>>>
>>> Thanks for the hard work improving our documentation!
>>>
>>
>> Daniel, thank you for looking at the document and the changes!
>>
>>
>>> While you are correct that a documentation change doesn't need a vote, I
>>> think it would be valuable if we can have one or two pairs of eyes look
>>> over these changes. I will try to do as much as I can but time is a bit
>>> limited.
>>>
>>
>> I couldn't agree more about the value of peer review! But intuitively I
>> feel that the backport nomination process involving STATUS isn't the best
>> approach in such scenarios. I genuinely feel that something is off with the
>> INSTALL commits accumulating in the STATUS file.
>>
>
> Yes, the STATUS file doesn't work in this case. I think it would be great
> of someone native English speaker could also take a quick glance at the
> file if something doesn't make sense from a grammatical (I had to look up
> the spelling!) point of view.
>
The thing is that most of the INSTALL changes have been structural so far.
There are about 170 new or updated lines of text (the whole file is now 888
lines, cut from 1576).
To make the peer review of these changes easier, I've prepared a file that
shows the new or updated content, grouped by section (attached
as INSTALL-r1936876-r1938493-updates.txt; it doesn't highlight the
structural changes made, though). I understand that it can be hard and
tedious to review the textual changes when some of the commits changed the
layout of the document, so I'm attaching the file to bring the focus back
to the text that was actually added or changed.
I feel that the review process of such documentation updates tends to drift
from the actual changes made to the current state of the document as a
whole (like highlighting issues that haven't been fixed yet). Such feedback
is important, but I think it should be handled separately from the review
of the changes themselves. The INSTALL rework is a work in progress, and
I'm collecting such feedback for upcoming commits. For the backport, I'd
like to keep the review focused on the changes themselves (i.e., on what is
actually being backported).
Thank you!
>
>>
>>> Some feedback, not only based on the parts you've touch but other things
>>> that now stand out from the stellar updates:
>>>
>>>
>>> In A.2 Building from a Working Copy:
>>>
>>> [[[
>>> You can discard the directory created by the tarball; you're
>>> about to build the latest, greatest Subversion client. This is
>>> the procedure Subversion developers use.
>>> ]]]
>>>
>>> Originally (see for example r849967) there were text about how to
>>> bootstrap your environment by building the svn binary from a release
>>> tarball and only later checking out a working copy and building. I believe
>>> this paragraph doesn't make sense in the current context and could be
>>> removed completely.
>>>
>>
>> Yep, that indeed looks like a leftover from some earlier step-by-step
>> guidance that first required the reader to build SVN from a tarball and
>> then proceed to building SVN from the latest source / a working copy. And I
>> agree this doesn't make sense with the current layout of the document.
>> Fixed in r1938205[1].
>>
>> [[[
>>> Start the process by running "autogen.sh":
>>>
>>> $ sh ./autogen.sh
>>>
>>> _This script will make sure you have all the necessary components
>>> available to build Subversion. If any are missing, you will be
>>> told where to get them from._ (See the 'Dependency Overview' in
>>> section I.)
>>> ]]]
>>>
>>> For me "necessary components" is APR and friends. As far as I can tell,
>>> autogen doesn't perform this check and for things it does check (for
>>> example autoconf) it only reports an error. I believe this was a thing
>>> before r840381.
>>>
>>
>> It appears that this description of autogen.sh was introduced in
>> r840624[2], and it seems to me that it was inaccurate even then, because it
>> described the pre-r840381 behavior. Prior to r840381[3], the script checked
>> for APR and neon and provided a hint if they were missing. This changed in
>> r840381, so it seems that the description was already out of date when it
>> was added.
>>
>> To fix this, I decided to remove the description in r1938214[4].
>>
>> BTW, I believe that with the autoconf-based build system, ./configure
>> handles dependency checking, not autogen.sh. E.g., when APR isn't found:
>>
>> [[[
>> configure: Apache Portable Runtime (APR) library configuration
>> checking for APR... no
>> configure: WARNING: APR not found
>> The Apache Portable Runtime (APR) library cannot be found.
>> Please install APR on this system and configure Subversion
>> with the appropriate --with-apr option.
>>
>> You probably need to do something similar with the Apache
>> Portable Runtime Utility (APRUTIL) library and then configure
>> Subversion with both the --with-apr and --with-apr-util options.
>>
>> configure: error: no suitable APR found
>> ]]]
>>
>>
>>>
>>> Under A.3 Building In a Separate Build Directory:
>>>
>>> [[[
>>> $ chmod +x autogen.sh
>>> $ ./autogen.sh
>>> ]]]
>>>
>>> I think the chmod is not required. autogen.sh is already svn:executable
>>> in any recent working copy (since r845231) and should be in all tar based
>>> release tarballs.
>>>
>>> For consistency, we might want to use sh ./autogen.sh here as well
>>> (compare above) or use only ./autogen.sh above.
>>>
>>
>> Let me think about this a little bit more. But sure, the formatting of
>> examples has to be consistent through the document and I'm in favor of just
>> ./autogen.sh.
>>
>
> For me, the unneccessary $ chmod was the main thing here. Consistency in
> formatting matters but less than a command that is effectively no-op.
>
>
>>
>>
>>>
>>> Under D.2 Running the test suite under the autoconf/make build system:
>>>
>>> Should we mention check-swig-[py, pl, rb]? I think they are important to
>>> run but of course they depend on building the bindings.
>>>
>>
>> I haven't yet dived into building and testing the bindings, but I think
>> that the topic needs to be covered in ./subversion/bindings/swig/INSTALL. A
>> link to the file will do I guess.
>>
>
> I think that's fine. I've sinced realised that swig/INSTALL mention the
> checks.
>
>
>>
>>
>>> Under IV. DEPENDENCIES IN DETAIL:
>>>
>>> [[[
>>> ...so if you are in a real hurry to get building, you can skip
>>> straight to section II.
>>> ]]]
>>>
>>> Reword the "skip straight to" part since we are now below section II?
>>>
>>
>> Since 'Dependencies in Detail' moved to the bottom of the document, I
>> think that these phrases are simply no longer necessary. Removed in
>> r1938215[5].
>>
>>
>>>
>>> Under 10. Python (https://www.python.org/) (OPTIONAL):
>>>
>>> [[[
>>> ...However, Support for Python
>>> 2.7 is being phased out.
>>> ]]]
>>>
>>> Lowercase "s"?
>>>
>>
>> Fixed in r1938203[6] where I updated the Python version requirements.
>>
>>
>>>
>>> Whole section 17. py3c (OPTIONAL)
>>>
>>> If I understand correctly, py3c is only required for the Python
>>> bindings. There is a separate document (subversion/bindings/swig/INSTALL,
>>> also referenced in INSTALL) for the bindings which also mention py3c. Swig
>>> details are only mentioned in the separate document. Does it make sense to
>>> remove py3c from INSTALL since it is covered elsewhere? Maybe just say
>>> something about "additional dependencies may be required for the bindings"
>>> in section IV? For reference we don't say anything about JDK in INSTALL,
>>> this is only mentioned in the javahl README.
>>>
>>
>> I haven't yet looked into the SWIG bindings topic. I believe that this is
>> a big topic just by itself and isolating it in a dedicated document
>> ./subversion/bindings/swig/INSTALL was a really good idea. IMHO moving the
>> details on building and testing the bindings away from the main INSTALL
>> file is a good decision. So I'm +1 on removing py3c from the main INSTALL
>> document.
>>
>
> +1
>
>
>>
>> Thank you!
>>
>> [1]: https://svn.apache.org/viewvc/?revision=1938205&view=revision
>> [2]: https://svn.apache.org/viewvc/?revision=840624&view=revision
>> [3]: https://svn.apache.org/viewvc/?revision=840381&view=revision
>> [4]: https://svn.apache.org/viewvc/?revision=1938214&view=revision
>> [5]: https://svn.apache.org/viewvc/?revision=1938215&view=revision
>> [6]: https://svn.apache.org/viewvc/?revision=1938203&view=revision
>>
>> --
>> With best regards,
>> Pavel Lyalyakin
>> VisualSVN Team
>>
>
--
With best regards,
Pavel Lyalyakin
VisualSVN Team
I.B Dependency Overview
You'll need the following build tools to compile Subversion:
* autoconf 2.59 or later and libtool 2.0 or later
(Unix only, for the autoconf-based build system)
or
* CMake 3.20 or later (Windows and Unix, for the
CMake-based build system)
* a reasonable C compiler (gcc, Visual Studio, etc.)
Subversion depends on the following third-party libraries. The easiest
way to install dependencies is via your operating system's package
management system.
Required:
* APR -- the portability layer that allows Subversion to
run on different operating systems.
* APR-util -- utility library built on top of APR.
* Expat -- XML parsing.
* zlib -- compression of binary diffs, used everywhere.
* LZ4 -- compression. A bundled copy can be used.
* SQLite -- used for some internal databases. An
amalgamation file can be used instead of an installed library.
* utf8proc -- UTF-8 support, including Unicode normalization. A bundled
copy can be used.
Optional:
* Apache Serf -- access to Subversion repositories over
http:// and https:// (client). Strongly recommended.
* Cyrus SASL -- SASL authentication for svn:// (client and svnserve
server).
* libmagic -- MIME type detection for files added to Subversion.
* libsecret -- password storage in GNOME Keyring (client, Unix-only).
* KDE Frameworks 5 with Qt 5 and D-Bus -- password storage in KWallet
(client, Unix-only).
* Python, Perl, Java, Ruby (with py3c for Python) -- the language
bindings.
* Apache HTTP Server -- the mod_dav_svn server module.
* Berkeley DB -- the deprecated BDB repository backend,
to be removed in the future (server).
II. INSTALLATION
Sections A and C below describe the classic build systems that have been
in use since 2001. Note that the Visual Studio vcproj build system is
deprecated as of Subversion 1.15 and will be removed in a future release.
Windows users should build Subversion with CMake instead.
Subversion's CMake-based build system was created in 2024 and was
included in Subversion 1.15. It is still under development and is
expected to become the default build system for Windows platforms
starting with Subversion 1.16. Section B below describes the CMake build
system.
II.A.2 Building from a Working Copy
This script generates the ./configure script.
II.B Building with CMake (Windows and Unix)
Windows tips:
- Modern versions of Microsoft Visual Studio support CMake projects
out of the box, including IntelliSense, an integrated CMake Settings
Editor, Test Explorer, and more. To use it for Subversion,
open the source directory in Visual Studio, and the configuration
should start automatically.
To change the build options (the CMake cache variables) in Visual
Studio, right-click the CMakeLists.txt file and click
'CMake Settings for Subversion' -- this opens the CMake Settings
Editor. Alternatively, you can edit the CMakeSettings.json file
directly.
After configuring the required settings, build the project as usual,
for example with Build > Build All.
See the following page for more information:
https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio
- vcpkg is a useful tool for bootstrapping the dependencies. It provides
ports for most of Subversion's dependencies, which can then be
installed with a single command.
To start using it, clone the vcpkg repository from GitHub, bootstrap
vcpkg, and install the dependencies:
[...snip...]
After this is done, vcpkg can be integrated into CMake by setting the
CMAKE_TOOLCHAIN_FILE variable to the path of the vcpkg file. To do
this in Visual Studio, open the CMake Settings Editor as explained in
the previous step, and put the following into the 'CMake toolchain
file' field, where VCPKG_ROOT is the path to your vcpkg clone:
II.C Building with vcproj/vcxproj (Windows only, deprecated)
The vcproj/vcxproj-based build system is deprecated since Subversion 1.15
and will be removed in a future release. See
[...snip...]
Windows users should build Subversion using CMake (see section B above).
The vcproj/vcxproj files for Visual Studio 2010 - 2022 can be generated
with gen-make.py. The required dependencies have to be present in the
system (built or installed) before generating the files. A minimal
gen-make.py command looks like this:
[...snip...]
The command generates the Visual Studio 2022 solution and project files
that can be used with Visual Studio and msbuild.
The 'python gen-make.py --help' command prints the list of the options
available, some of which can be used when generating the project files.
To run the test suite, build the target __ALL_TESTS__ and run
C:\SVN\src>python win-tests.py -c -r
The 'python win-tests.py --help' command prints the list of available
options.
II.D.3 Running the test suite under the CMake build system
The tests are built when the SVN_ENABLE_TESTS option is set to ON.
Run the ctest command from the build directory to run the tests.
II.E Building a Subversion server
Subversion has two servers you can choose from, svnserve and
Apache HTTP Server (httpd):
- svnserve is a small, lightweight server program that makes Subversion
repositories available to clients over a custom protocol. The svnserve
server is automatically compiled when you build Subversion's source.
- Apache HTTP Server is a "heavy-duty" server for which the Subversion
project provides the mod_dav_svn and mod_authz_svn modules. Please
refer to section IV.9 below for more information.
SVNBook provides an overview of the server options as well as the steps
necessary to configure these servers in 'Chapter 6. Server
Configuration':
IV.1 Apache Portable Runtime and APR-util (REQUIRED)
Subversion requires APR 1.4 or later and APR-util 1.3 or
later.
IV.2 Expat (REQUIRED for client and server)
Subversion uses the Expat library for XML parsing.
IV.3 SQLite (REQUIRED)
To use an SQLite-provided amalgamation, just drop sqlite3.c into
Subversion's sqlite-amalgamation/ directory, or point to it with the
--with-sqlite configure option. The amalgamation can be obtained
from the official SQLite website:
IV.5 LZ4 (REQUIRED)
Subversion requires LZ4 version r129 or later.
Subversion uses the LZ4 library for compression. Configure will attempt
to locate the system library by default using pkg-config and known paths.
IV.7 Apache Serf library (OPTIONAL)
The minimum supported version is 1.3.4.
[...snip...]
Apache Serf uses OpenSSL for the encrypted https:// communication.
In order to use ra_serf, you must install serf. Configure will
attempt to locate libserf by default using pkg-config.
If you don't use pkg-config and serf is installed in a non-standard
location, then use:
IV.9 Apache HTTP Server (httpd) (OPTIONAL)
The minimum supported version is 2.2.
The Apache HTTP Server (httpd) can be used to make your Subversion
repositories available over a network. To make this happen, Subversion
provides two modules for the server:
- mod_dav_svn -- enables Apache HTTP Server to serve the repositories
over HTTP(S).
- mod_authz_svn -- enables granular access control for your repositories.
A third, auxiliary module, mod_dontdothat, is also available. It's
designed to block typically unwanted heavy requests.
Building the modules requires Apache HTTP Server to be installed in the
system and its development headers to be present as well.
Building the modules with autoconf/make:
Configure looks for the apxs tool of httpd in the standard locations and
builds the modules if it's found. You can use the "--with-apxs=" option
to locate apxs if it's not found automatically:
$ ./configure --with-apxs=/usr/local/apache2/bin/apxs
The modules are shared objects, so don't use the '--disable-shared'
option.
By default, 'make install' installs the modules into Subversion's
libexecdir (/usr/local/libexec, by default). Use
'--with-apache-libexecdir' to
install them into httpd's own module directory
(e.g., /usr/lib/apache2/modules) or '--with-apache-libexecdir=SOMEPATH'
to install them into SOMEPATH.
The '--enable-mod-activation' option adds the LoadModule directives
to the httpd's configuration files automatically.
Building the modules with CMake:
CMake builds the modules when the SVN_ENABLE_APACHE_MODULES option
is set to ON (the command-line option is -DSVN_ENABLE_APACHE_MODULES=ON).
On Windows, the import libraries libhttpd.lib and mod_dav.lib are
required. Point CMake at the httpd installation directory (e.g.,
C:\Apache24) using the CMAKE_PREFIX_PATH variable, or specify
HTTPD_INCLUDE_DIR, HTTPD_LIBRARY and MOD_DAV_LIBRARY explicitly (e.g.,
C:\Apache24\include, C:\Apache24\lib\libhttpd.lib and
C:\Apache24\lib\mod_dav.lib respectively).
Next steps:
Configuring Apache HTTP Server or svnserve, Subversion's own server
program, is described in chapter 6 of the Subversion Book:
IV.10 Python (https://www.python.org/) (OPTIONAL)
The minimum supported version is 3.6.
[...snip...]
Python 2.7 reached end of life on January 1, 2020. All users are
strongly encouraged to move to Python 3. The SWIG Python bindings can
still be built for Python 2.7 with the autoconf-based build system.
Please see the file ./subversion/bindings/swig/INSTALL for more
information.
IV.18 Berkeley DB (DEPRECATED, TO BE REMOVED IN THE FUTURE)
The minimum supported version is 4.0.14.
Needed only for the deprecated BDB repository backend. Support for
BDB is planned to be removed completely in the future.
The CMake build system does not support building with BDB.
IV.19 autoconf (Unix only)
The minimum supported version is 2.59.
This is required only if you plan to use the autoconf-based build system
and build from a working copy (see section II.A.2).
IV.20 libtool (Unix only)
The minimum supported version is 2.0.
This is required only if you plan to use the autoconf-based build system
and build from a working copy (see section II.A.2).
IV.21 CMake
The minimum supported version is 3.20.
This is required only if you plan to use the CMake-based build system
(see section II.B).
