If you’re reading this, you probably know that Freepository began offering integrated SVN & Trac accounts on January 1st of this year. We have many, many members, and as a result, the service gets put through numerous use cases every day. Most of these we’ve considered, modeled and designed to or around. Occasionally we encounter a new one.
The snippet below was sent to us by one of our members who is Beta-testing our new SVN ACL implementation. The details of the exact issue & resolution aren’t important for this posting – we’re focusing instead on the very alarming – and misleading – error message “wrong version number”:
svn: PROPFIND request failed on
svn: PROPFIND of ‘/some/path/to/your/svn/repository’: Could not
read status line: SSL error: wrong version number
The PROPFIND errors are tricky, because many of them are generic, or simply pass through whatever the underlying call has provided..
This particular error, about “wrong version number” used to show up in cvs-sserver operations when a user didn’t have appropriate access. The challenge in dealing with the error messages is that there are three different sets of libraries involved in servicing any transaction – Subversion, Apache HTTPD, and OpenSSL. This particular error bubbles up from OpenSSL and almost always is triggered by an “access denied” type of HTTPS request/response.
A Silver account member is the owner of any SVN/Trac he/she has created, and can create new users directly in the Admin console of the Trac view. This is very powerful, and provides our members the flexibility of managing the users in their SVN/Trac name-space without the need for any of those users to have a full Freepository account.
Trac access privileges are applied to the Trac name-space, which utilizes a simple .htusers file to provide access control in both SVN and Trac. In the absence of any additional ACL, such as an svnconf file, the .htusers list is authoritative for the combined SVN/Trac name-space. In the case of a SVN repository that does have an svnconf file (like our Beta tester), there is another ACL in the raw SVN name-space. SVN now sees this as authoritative for access & changes to the raw repository. When an attempt is made to gain access to the raw SVN repository by a user who has Trac privileges but isn’t in the svnconf file, this attempt fails. It should fail with an access denied error, but instead throws the ominous “wrong version number” message.
If you have followed this posting closely, you’ll realize that the “wrong version number” error message is nearly completely meaningless. Our current work involves integrating these two ACL mechanisms, such that we create the behavior of a single, unified ACL.