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! 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. 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. [[[ 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. 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. 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. 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? Under 10. Python (https://www.python.org/) (OPTIONAL): [[[ ...However, Support for Python 2.7 is being phased out. ]]] Lowercase "s"? 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. Kind regards, Daniel
