I'm on OS Sierra.

I currently have subversion 1.9 and I want to downgrade to 1.7.

I tried this so far with no luck:

$ brew tap homebrew/versions
$ brew install subversion17
Error: No available formula with the name "subversion17" 
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching taps...
Error: No formulae found in taps.
$ brew search subversion

What other options might I have?

Edit: More background:

I'm getting this message when I run svn commands in my working directory:

> svn: E155036: Please see the 'svn upgrade' command svn: E155036: The
> working copy at '/Users/MyProject' is too old (format 29) to work with
> client version '1.9.4 (r1740329)' (expects format 31). You need to
> upgrade the working copy first.

I'm worried if I run the upgrade I won't be able to talk to the server anymore? And I have no control over what version the server is running and I don't think they would be willing to upgrade it.

  • So you are running a svn 1.9.4 client ?? – Rene Larsen Feb 14 '17 at 14:47
  • You're correct. I updated the question. – Greg Feb 14 '17 at 15:08
  • @Greg What happens if you backup your working copy, then run svn upgrade to find out whether it works? Mind that svn upgrade is not going to affect server state; this means you can always return to your backed-up working copy in case something goes south. – Synoli Feb 14 '17 at 15:18


  • your SVN client tells you it wants you to upgrade your working copy from format 29 to format 31,

  • and the server is not under your control,

  • and you’re not sure whether the server is going to support the newer format,

then these steps might help you get an updated working copy:

  1. Make a backup of the entire folder that is your working copy, including all subdirectories, especially those named .svn. Store your backup in a safe place that is outside your working copy.

  2. If you’re comfortable with losing your uncommitted changes, you can simply check out a fresh working copy. Clients are made to work with old servers, so chances are this is the easiest option for you. If you’re fine with that, stop here. There is no step 3.

  3. If you’re still determined to upgrade your existing working copy, cd to it and run svn upgrade. Don’t worry about breaking something; svn upgrade is not going to affect server state. If it fails, simply restore your backup or check out a fresh working copy.

  4. If svn upgrade succeeds, you might want to make sure whether the server is still going to well with your newly upgraded working copy. So it’s time to do a quick check and see for yourself. To prepare for that, do svn update first. If svn update fails, try fixing all the issues before you go on to the next step.

  5. As a final test, make a change and check it in so you can see whether the server accepts that, too. For example, create a dummy change you’re comfortable with checking into the repository, e. g. a new file named deleteme.txt. Or just add a newline to some existing source code. If your working copy already has some uncommitted changes you’re comfortable with committing, you can simply use those.

  6. Commit the changes you’ve chosen.

  7. If svn commit returns an error, you still have a few options: as a first step, try and fix the issue yourself; or open another question to ask for help (stating exactly what you did, what you expected, and what actually happened); or edit your existing question; alternatively, simply check out a fresh working copy (see step 2). No matter what, do not be tempted to downgrade your Subversion client to version 1.7.

| improve this answer | |
  • 1
    Thanks! I ended up going with option 1 and it's working fine. – Greg Feb 17 '17 at 21:19

Whatever your underlying motivation or use case is: I personally recommended that you do not downgrade. Downgrading to Subversion 1.7 will put your Mac at risk.

Also, for technical reasons, Subversion 1.7 cannot run on El Capitan or later unless a developer is willing to spend considerable effort.

The subversion17 formula was deleted from Homebrew last month, albeit for unrelated reasons. Before it got deleted, a comment in the formula said:

# Requires system OpenSSL headers to build. >El Capitan no longer ship them.
# Note this means that this subversion is linked against an outdated OpenSSL
# and really should not be considered secure.

In other words, not only is Subversion 1.7 unsafe to use on macOS; also, El Capitan or later versions of macOS cannot run 1.7 because the required header files are missing.

For the same reason, well-known Subversion download sources, e. g. WANdisco’s download page, offer Subversion 1.7 releases for OS X Yosemite or earlier but not for current macOS versions.

An alternative approach would be that you post a new question (or edit your existing one) to give more information on what your underlying motivation is.

  • What are you actually trying to achieve specifically with the 1.7 release?

  • What specific issue(s) do you anticipate, or have already encountered, using the latest release of Subversion instead, or any other version control package?

| improve this answer | |
  • Thanks for the answer. See my edit the question for my specific issue. Let me know if you have any ideas. – Greg Feb 14 '17 at 13:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .