The following steps reproduce the behaviour filed in the bug report



0. Start with an empty authz file:


Verified that authz file that I used is clean by overwriting it, making it clean:


{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} ll svnaccess.conf
-rw-r--r-- 1 someuser someuser 11 Apr  3 02:49 svnaccess.conf
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} > svnaccess.conf 
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} ll svnaccess.conf
-rw-r--r-- 1 someuser someuser 0 Apr  3 02:49 svnaccess.conf


At this point I do the following (in this order):
1. open up a web browser
2. then goto my Trac project page
3. then login with an account which has admin privlages (thereby permitting viewing the Admin button on Trac toolbar)
4. then click on the "Admin" button on the Trac toolbar
5. then on the right hand side under "Administration, click on "Subversion Access" (listed under the "Subversion" heading)


In the "Manage Subversion Access Rights" screen, no content appears, as shown here:

screenshot001


Observation: Accessing the "Manage Subversion Access Rights" page seems to set up the authz file, as so:



Verify: When when I look at the authz file, I see it has this as it's contents:

{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} cat -n svnaccess.conf 
1
2  [groups]
3


Now, Add a path named: /new_path

see: screenshot002
see: screenshot003


Contents of the authz file after the above action:
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} cat -n svnaccess.conf
1
2  [groups]
3
4  [/new_path]
5




Now, Add a path named /test_path

screenshot004
screenshot005

Contents of the authz file after the above action:
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} cat -n svnaccess.conf
1
2  [groups]
3
4  [/new_path]
5
6  [/test_path]
7


Now, lets remove the /new_path entry:


screenshot006
screenshot007



Contents of the authz file after the above action:
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} cat -n svnaccess.conf
1
2  [groups]
3
4  [/test_path]
5


Now, Add a path named /new_path:

screenshot008
screenshot009


Contents of the authz file after the above action:
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} cat -n svnaccess.conf
1
2  [groups]
3
4  [/test_path]
5
6  [/new_path]
7



Now, lets remove the /new_path entry:

screenshot010
result: screenshot011


Contents of the authz file after the above action:
{someuser@somecomputer:/home/someuser/trac-0.10.4-9/trac/conf} cat -n svnaccess.conf
     1
     2  [groups]
     3
     4  [/new_path]
     5





Result:
* /new_path was not removed (as desired by the user)
* /test_path was instead removed (not desired by the user)





Also: A simpler test case of this also produces the same result:


* Add /test_path first (via the plugin)
* Add /new_path second (via the plugin)
* Refresh the plugin page / click to another page [if you want] 
* You will notice that the "Subversion Paths" section of "Manage Subversion Access Rights" will show /new_path first and /test_path second
* If you look at the authz file, you will see:
$> cat -n svnaccess.conf
     1
     2  [groups]
     3
     4  [/test_path]
     5
     6  [/new_path]
     7

* Select the first entry listed on the page, which is next to the entry for */:new_path (do this via the plugin)
* Click "Remove selected paths"
* The page refreshes and still shows: *:/new_path
* The file shows:
$> cat -n svnaccess.conf
     1
     2  [groups]
     3
     4  [/new_path]
     5


Result:
* /new_path was not removed (as desired by the user)
* /test_path was instead removed (not desired by the user)