Update 1.10 release notes

Signed-off-by: James McCoy <jamessan@debian.org>

1 files changed, 71 insertions, 12 deletions

diff --git a/debian/svn_1.10_releasenotes.html b/debian/svn_1.10_releasenotes.html
index 3111aba..d4c85ca 100644
--- a/debian/svn_1.10_releasenotes.html
+++ b/debian/svn_1.10_releasenotes.html
@@ -370,22 +370,81 @@ selected while 1.10 combines all the lines to give read-write access.
 The 1.10 implementation may change in future releases, perhaps to
 <a href="/issue/4794">make this case an error</a>.</p>
 
-<p>The 1.9 implementation combined the global and per-repository rules
-for the same path:</p>
+<p>A fix for <a href="https://issues.apache.org/jira/browse/SVN-4762?issueNumber=4762"
+>Issue #4762</a> may change the way path-based authorization rules are applied
+in some circumstances. See <a href="http://svn.apache.org/r1882326">r1882326</a>.</p>
+
+<p>Background: Subversion 1.10 introduced a new implementation of path-based
+authorization (authz) to deliver wildcard support and improved performance
+over that of Subversion 1.9 and earlier. From Subversion 1.10 through 1.14.0,
+the new implementation did not correctly combine global rules with repository
+rules: if a global rule and a per-repository rule were both present for a
+path, the global rule would be ignored and the per-repository rule would
+apply by itself. As a result, from Subversion 1.10 through 1.14.0, it was not
+possible to override per-path access rules for specific users (or groups) at
+the global level. Administrators whose authz rules rely on this incorrect
+behavior may need to adjust their rules accordingly.
+</p>
+
+<p>This issue is fixed in 1.14.1, making it possible once again to
+override per-path access rules for specific users (and groups) at the global level.
+Such global rules are overridden by repository-specific rules only if both the
+user and the path match the repository-specific rule.</p>
+
+<p>As an example, consider the following rule set:</p>
 
 <pre>
-  [/some/path]
-  userA = rw
-  [repository:/some/path]
-  userB = r
+[groups]
+company = developer1, developer2, developer3
+customer = customer1, customer2
+
+# company can read-write on everything
+[/]
+@company = rw
+
+[project1:/]
+@customer = r
 </pre>
 
-<p>In 1.9 this would define access for both <tt>userA</tt>
-and <tt>userB</tt>, in 1.10 the per-repository rule overrides the
-global rule and this only defines access for <tt>userB</tt>.  The 1.10
-implementation may change in future releases, but the exact change
-is still being <a href="/issue/4762">discussed</a> on the dev mailing
-list.</p>
+<p>
+Does <tt>developer1</tt> have <tt>rw</tt> access to <tt>"/trunk"</tt> in <tt>project1</tt>?
+</p>
+
+<p>
+Subversion servers running 1.10.0 up to 1.10.6 or 1.14.0, without the fix for
+<a href="https://issues.apache.org/jira/browse/SVN-4762?issueNumber=4762"
+>issue #4762</a>, will only apply the repository-specific part of the rule set:</p>
+<pre>
+[project1:/]
+@customer = r
+</pre>
+<p>
+The answer in this case is that <tt>developer1</tt> has no access at all because the
+global rule which grants <tt>rw</tt> access to the <tt>@company</tt> group is ignored.
+</p>
+
+<p>
+Subversion servers running 1.14.1 or later match the behaviour of
+Subversion 1.9, meaning they will apply both the global and the repository-specific
+part of the rule set:</p>
+<pre>
+# company can read-write on everything
+[/]
+@company = rw
+
+[project1:/]
+@customer = r
+</pre>
+<p>
+The answer in this case is that <tt>developer1</tt> has <tt>rw</tt> access
+to any path in <tt>project1</tt>.
+Global rules are overridden by repository-specific rules only if both the
+user (<tt>developer1</tt>) and the path (<tt>"/"</tt>, including child paths
+for which no specific rules exist) match the repository-specific rule.
+While the repository-specific rule matches <tt>"/trunk"</tt> it does not
+match <tt>developer1</tt>, and hence the global rule will be used.
+</p>
+
 
 </div>  <!-- authz-compatibility -->