* www/index.it.html
Remove links to the mailing list information
Format the text nicely.
Add ( ) to print to make it Py3 compatible
[fr] Keeping in sync with English version.
Merge from ^/trunk/en r6063.
Update outdated links
Externals lines starting with '#' are ignored
Committed to trunk/en; backported to branches/1.7/en.
Merge from ^/trunk/en r6061.
Issue #284: Document the externals definitions comment syntax.
How about adding a new paragraph [[[ A line starting with # is interpreted as a comment. ]]] right after the first example?
* www/index.zh.html
Externals lines starting with '#' are ignored
[fr] fixing typo.
Keeping French branch in sync with English version.
Replace http:// links with https:// and update links when the old target no longer exists.
Replace old/broken link to Cyrus SASL with the current url.
1.8/zh: minor tuning
Keeping French branch in sync with English version.
1.8/zh: translation of r6052
1.8/zh: merge changes from trunk, translation todo
* ch03-advanced-topics.xml
I still have a lingering nag here. I assumed the executable bit was a feature of the filesystem, not of the OS. Yet, "system calls" are a feature of the OS. It's common to have, say, a FAT32 volume mounted in Linux. But does the reverse occur, where an ext3 filesystem is mounted in Windows? It sounds like APR won't try to set an executable bit on such a filesystem. What about network filesystems? Will APR preserve the executable bit on, say, an NFS mount when accessed via Windows?
(y) It also doesn't have an effect on OS2, but I don't know how relevant it is these days.
As I read this, I believe the OP is not suggesting that Subversion behaves any differently than the book describes, but rather that the text misrepresents NTFS as not having a notion of an executable permission bit. Unfortunately, the proposed fix causes a different confusion by allowing an NTFS-knowledgeable person to assume that Subversion will conditionally set that bit on NTFS (which, of course, it does not). Perhaps the text could be changed to read instead: This property has no effect on Windows...
As I read this, I believe the OP is not suggesting that Subversion behaves any differently than the book describes, but rather that the text misrepresents NTFS as not having a notion of an executable permission bit. Unfortunately, the proposed fix causes a different confusion by allowing an NTFS-knowledgeable person to assume that Subversion will set that bit on NTFS (which, of course, it does not). Perhaps the text could be changed to read instead: This property has no effect on Windows or on filesystems...
I'm not so sure about this. Indeed NTFS has a "Read and execute" permission, but Subversion doesn't (as far as I can tell) sent any NTFS permissions. I tried to trace the svn:executable property and it seems to end up in svn_io_set_file_executable. There is a comment: [[[ On Windows and OS/2, just exit -- on unix call our internal function which attempts to honor the umask. ]]] According to my tests, a new file inherits the "Read and execute" permission from the parent directory when it is checked...
Sync with en revision.
* trunk/tools/bin/spew-svn-command-options
Sync with en revision r6040
1.8/zh: resolve some TODO
1.8/zh: merge changes from trunk
1.8/zh: minor tuning
1.8/zh: minor tuning
[fr] Keeping in sync with English version.
Followup to r6041, restore default FO_XLSTPROC_OPTS from r5129.
The changes in r5129 override any customization to FO_XSLTPROC_OPTS in
Unable to build pdf from source
I agree that line endings are the likely problem. I suspect that the average non-SVN-dev building the book from source are a rarity (sorry Thomas -- it just means you're special!). For such, the workaround you've suggested should be sufficient. I don't see a reason to change the svn:eol-style property to accommodate this scenario, especially when one can also choose to use svn export --native-eol=LF on such systems to get the book sources (albeit not in a working copy) into the necessary line-ending...
I've tweaked the configuration to hopefully do said notification to svnbook-dev@.
Let's continue this discussion on the list? These tickets don't get Cc'd to it, AFAIK.
I believe this error might come from the fact that the working copy, as configured in the linked e-mail, is checked out using Windows line-endings (\r\n). However the script is executed by bash in WSL, expecting Linux line-endings (\n). I was able to make it work by converting the line endings in run-fop.sh from "Windows (CRLF)" to "Unix (LF)" in Notepad++. It should be possible to make this conversion automatic by changing the svn:eol-style property but that might break things for anyone expecting...
Possible TLS certificate problem on SVN Book page(s)
Possible TLS certificate problem on SVN Book page(s)
A correct SSL certificate was added by C. Michael Pilato in July 2021. See http://mail-archives.apache.org/mod_mbox/subversion-dev/202107.mbox/%3CCABUQHU7xRWmNAO1K115eeMOwAPs7zp8RA0T1nBMdSn%2B5XNVg%2BQ%40mail.gmail.com%3E
Replace a few tigris.org links.
Convert the nightly build script to Python 3.
1.8/zh: add some missing translation
1.8/zh: resolve a TODO
1.8/zh: remove a TODO about Hollywood movie
1.8/zh: resolve a TODO
Dalavan's Domain Subversion
1.14: Port Python examples to Python 3
Port Python examples to Python 3
1.8/zh: resolve some TODO
1.8/zh: resolve some TODO
1.8/zh: resolve one TODO
1.8/zh: resolve some TODO
1.8/zh: resolve some TODO
1.8/zh: resolve some TODO
1.8/zh: resolve some TODO
1.8/zh: resolve some TODO
1.8/zh: merge changes from trunk
1.8/zh: resolve some TODO
1.8/zh: whole book reviewed, but still have some TODO to resolve
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
* ch06-server-configuration.xml
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: review of whole book in progress
1.8/zh: resolve some TODO
1.8/zh: resolve some TODO
1.8/zh: merge and translate changes from trunk
1.8/zh: index reviewed
Yes, unfortunately the cert we use is for "red-bean.com" generically, and not "svnbook.red-bean.com" specifically.
Possible TLS certificate problem on SVN Book page(s)
1.8/zh: index translated, but review needed
Originally posted by: cmpilato Closing as Invalid per the reporter's request. Status: valid
* en/book/ch04-branching-and-merging.xml
1.8/zh: translation of index in progress, plus some review
1.8/zh: resolve some TODO
1.8/zh: pdf: decrease space before and after of verbatim tag
1.8/zh: resolve some TODO
1.8/zh: in pdf, using font DroidSansFallback as bold form of SimSun
1.8/zh: make some tunings for pdf:
1.8/zh: update font of pdf, which is more consistent with html.
1.8/zh: using font of kaiti for characters within <emphasis> and <firstterm>
* www/index.zh.html
1.8/zh: pdf looks good, now
1.8/zh: whole book reviewed, but still has some TODO to resolve
1.8/zh: review of whole book in progress, svnserve and svnversion reviewed
1.8/zh: review of whole book in progress, svnlook reference reviewed
