For the Subversion example, assuming you're using Subversion over HTTP, the situation is much simpler. Assuming the svn client had OAuth support built in, the flow would go something like this:

1. svn client makes unauthenticated request to svn.example.com
2. svn.example.com returns 401 Unauthorized response, with WWW-Authenticate header indicating support for OAuth
3. svn client, which comes pre-configured to talk to svn.example.com (/me waves hands madly in air) makes request to svn.example.com's Request Token Endpoint and obtains Request Token
4. svn client then indicates to user that they need to go to svn.example.com's Authorization Endpoint with the request token as a parameter. This might be automated in environments where it's possible to do so.
5. User goes to svn.example.com's Authorization Endpoint and asserts that they want to give svn client permission to access the subversion repository.
6. svn.example.com indicates to the user that they need to tell svn client that they've given it permission. svn client waits patiently in the background, with a prompt saying "Have you done the thing yet?"
7. User tells svn client that they've given it permission and that it should continue.
8. svn client makes a signed request to svn.example.com's Access Token request Endpoint to obtain the Access Token.
9. All subsequent requests against svn.example.com are authenticated normally with OAuth, similarly to the way Subversion currently (often) uses Basic Auth until the user decides to revoke access to svn client.