Subversion

svn: file is scheduled for addition, but is missing

Posted on by hb

If you add a file in subversion and then delete it before commiting e.g.:

$ touch myfile
$ svn add myfile
A         myfile
$ rm myfile

And then commit, you will get the following error message:

$ svn ci
svn: Commit failed (details follow):
svn: 'myfile' is scheduled for addition, but is missing

There are two possibilities to fix it.

Either you have to revert it:

$ svn revert myfile
Reverted 'myfile'

Or you have to forcefully delete it:

$ touch myfile
$ svn delete --force myfile

After that you can commit without errors. Of course, if you have multiple such files, you’ll have to take care of each one of them before commiting.

To find such files, you can use the svn command status:

$ svn status
!       myfile

If the deleted file was a folder, you’ll have to revert not only this one folder but all children files and folders:

$ svn revert myfolder --depth infinity

In order to prevent this problem, you should rather use the svn command rm instead of removing the file using the operating system command e.g.:

$ svn rm --force myfile

Google +

Linkedin

SVN: ra_serf was compiled for serf 1.3.4 but loaded an incompatible 1.2.1 library

Posted on by hb

When trying to check out my latest WordPress plugin on my Mac, I got the following error message:

# svn co http://plugins.svn.wordpress.org/wp-advertize-it wp-advertize-it
svn: E200019: ra_serf was compiled for serf 1.3.4 but loaded an incompatible 1.2.1 library

The reason for this error message is that although there is no separate Serf package in Homebrew anymore and it is included as a private package in SVN and was still on my machine. So I had to remove it:

# brew remove serf
Uninstalling /usr/local/Cellar/serf/1.2.1...

Now of course the library is missing, so SVN still does not work:

# svn co http://plugins.svn.wordpress.org/wp-advertize-it wp-advertize-it
dyld: Library not loaded: /usr/local/lib/libserf-1.0.dylib
  Referenced from: /usr/local/bin/svn
  Reason: image not found
Trace/BPT trap: 5

So you need to uninstall SVN:

# brew uninstall svn
Uninstalling /usr/local/Cellar/subversion/1.8.8...

and reinstall it:

# brew install svn
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/subversion-1.8.8.mavericks.bottle.1.tar.gz
######################################################################## 100.0%
==> Pouring subversion-1.8.8.mavericks.bottle.1.tar.gz
==> Caveats
svntools have been installed to:
  /usr/local/opt/subversion/libexec

Bash completion has been installed to:
/usr/local/etc/bash_completion.d
==> Summary

Google +

Linkedin

SVN: Subversion 1.8 on Debian 7 (Wheezy)

Posted on by hb

Debian 7 (Wheezy) is still only shipping with Subversion 1.6 (see Details of package subversion in wheezy).

First you need to add the WANdisco GPG key to the apt sources keyring:

$ wget -q http://opensource.wandisco.com/wandisco-debian.gpg -O- | apt-key add -

Then you need to add the appropriate apt source. You can either extend /etc/apt/sources.list or create a new file in /etc/apt/sources.list.d. We’ll go for the second option:

$ echo "deb http://staging.opensource.wandisco.com/debian wheezy svn18" > /etc/apt/sources.list.d/subversion.list

Now you can have apt-get download the package lists from the new repository and update the dependencies:

$ apt-get update

Now apt-cache will show you (at least) two versions:

$ apt-cache show subversion
Package: subversion
Version: 1.8.8-3+WANdisco
Architecture: amd64
Maintainer: Philip Herron <opensource@wandisco.com>
Installed-Size: 4423
Depends: libsvn1 (= 1.8.8-3+WANdisco), libapr1 (>= 1.3.2), libaprutil1 (>= 1.2.7+dfsg), libc6 (>= 2.3), libexpat1 (>= 2.0.1), libsasl2-2 (>= 2.1.24), zlib1g (>= 1:1.1.4)
Suggests: subversion-tools, db4.8-util, patch
Filename: dists/wheezy/svn18/binary-amd64/subversion_1.8.8-3+WANdisco_amd64.deb
Size: 1453080
MD5sum: 8b23345878430ab7c5d22aabd461bbd6
SHA1: bc8125dfcc3c7bee34b09eca6919d5e64a7513d4
SHA256: 861987aebdcd2fa9f03ba9f758572fb05f8b345341533c0d072b5ef573443999
Section: vcs
Priority: optional
Homepage: http://wandisco.com
Description: Advanced version control system

Package: subversion
Version: 1.6.17dfsg-4+deb7u4
Installed-Size: 4108
Maintainer: Peter Samuelson <peter@p12n.org>
Architecture: amd64
Depends: libsvn1 (= 1.6.17dfsg-4+deb7u4), libapr1 (>= 1.2.7), libc6 (>= 2.3), libsasl2-2 (>= 2.1.24)
Suggests: subversion-tools, db5.1-util, patch
Description: Advanced version control system
Homepage: http://subversion.apache.org/
Description-md5: 15da1bb51fb2e9ea5e25b3a489b864d9
Tag: devel::rcs, implemented-in::c++, implemented-in::python,
 interface::commandline, network::client, network::server,
 protocol::http, protocol::ssh, protocol::webdav, role::program,
 use::storing, use::synchronizing
Section: vcs
Priority: optional
Filename: pool/main/s/subversion/subversion_1.6.17dfsg-4+deb7u4_amd64.deb
Size: 1319636
MD5sum: 608ed74ad8856546afd0a38ad171d0a5
SHA1: 46b53dc63ae20c59c39e152d65d68397c951051f
SHA256: a4a7fd1aefc7f160aa4a270792e5b7812a3804623d36b34f41055ed7a4b083a0

You can now install the new version using:

$ apt-get install subversion

Now Subversion 1.8 will be installed, you can check it with:

$ svn --version
svn, Version 1.8.8 (r1568071)
...

If you have already done all this for Subversion 1.7 and only want to upgrade to versino 1.8, it’s even easier. You just have to find where the source is defined (you don’t need to import the key as you already have it):

$ grep -R svn17 /etc/apt/
/etc/apt/sources.list.d/WANdisco.list:deb http://staging.opensource.wandisco.com/debian wheezy svn17

Then replace svn17 by svn18 in this file:

$ sed -i 's/svn17/svn18/' /etc/apt/sources.list.d/WANdisco.list

Now you can have apt-get download the package lists from the new repository and upgrade subversion:

$ apt-get update && apt-get upgrade

Google +

Linkedin

SVN: This client is too old to work with working copy

Posted on by hb

Similar to the error message:

The working copy at XXX is too old (format XXX) to work with client version XXX (rXXX)’ (expects format XX). You need to upgrade the working copy first.

which indicates that the current client version is not able to work with a working copy made by an old svn version (in which case you need to perform an svn upgrade in the working copy), you can get the opposite error message saying:

This client is too old to work with working copy ‘XXX’. You need to get a newer Subversion client, or to downgrade this working copy.

This means that you have used a newer version to create the working copy or have upgraded the working copy with a newer version of svn. This is usually caused by one of the following:

  1. You have reinstalled an old version of svn.
  2. You have multiple versions of svn installed and are just using the wrong one.
  3. You get this error in a tool like Eclipse which ships with its own version of svn and the working copy was upgraded from the command line which uses a newer version of svn.

For the first problem, the solution is pretty simple: update your svn installation to a newer version.

For the second problem, execute the following to check which version of svn you are using:

svn --version

It will probably show you that you are using an outdated version of svn. If you do not need anymore, the best way to solve it is to uninstall this outdated svn version and make sure that the newer version is available in the path. If you do need it, then you’ll need to access this working copy using the full path to the newer svn executable.

If you’re getting this error in Eclipse using subclipse, check that you have the write version of subclipse installed as shown at the end of this post.

Note that a downgrade from version 1.7 to version 1.6 or lower is not possible because the internal formats are not compatible. In all cases a downgrade is definitely not the way you want to go. If you need to have working copies using different versions of subversion, the best solution is to use an absolute path to the svn executable.

Google +

Linkedin

Mixed git and svn working copy

Posted on by hb

Since I am working on project where the code is:

  • currently in an SVN repository
  • will be available on GitHub to the community
  • will stay in SVN for use in internal projects

As I was trying to figure out a way to have this work with people making changes on the public version on GitHub, others making changes in the private version in SVN and in most cases propagating all changes in both directions. One idea is to have some working copies which are SVN only, some which are Git only and some which are both a Git and an SVN Working Copy and can be used to propagate changes.

Setup

The structure would looks like this:

playground git svn mix

So first I created the directories:

cd ~
mkdir playground
cd ~/playground
rm -rf ~/playground/svn ~/playground/git ~/playground/mix
mkdir ~/playground/svn ~/playground/git ~/playground/mix

Then the working copies:

git clone https://github.com/benohead/my_product_name.git ~/playground/git/my_product_name

svn co --username my_user --password my_password --non-interactive http://my_private_server/svn/my_product_name ~/playground/svn/my_product_name

git clone https://github.com/benohead/my_product_name.git ~/playground/mix/my_product_name
svn co --username my_user --password my_password --non-interactive http://my_private_server/svn/my_product_name ~/playground/mix/my_product_name

It can be done in almost any order but for the “mix” directory, you need to first create the git clone and then checkout from svn as git will complain if the directory is not empty.

Since the files were already there when we checked out, you’ll probably have many conflicts. It’s the reason I used the –non-interactive option. Like this the checkout happens without having to handle the conflicts right now. But later on, you’ll need to handle them in order to be able to check in. So we have two solutions either keep the GitHub files or use the SVN files (i.e. revert to the repository version).

Keeping the GitHub files

If you want to keep the GitHub files i.e. have the GitHub version of the files in both the GitHub and the SVN repositories, the first idea is probably to resolve the conflict saying we want to keep the working copy e.g.:

cd ~/playground/mix/my_product_name
svn resolve --accept working -R *

Unfortunately after you do this, all files will be marked for deletion. This is because the files we have in there were there before the first checkout so they are considered unversioned files. So since there are no locally modified versioned files, svn will consider that when you say that you want to keep the local copy, you actually mean you want to delete the files. So after running the previous command, if you then commit, you’ll just delete all files.

So what do we do ? Can we only keep the svn version and not the GitHub version ? Of course not. The solution is actually pretty easy.

First, revert all files in the svn working copy. 

svn revert -R *

After that you have the version from SVN (not what you want) but the conflicts are all gone. Then you reset in git to get back to the versions from GitHub:

git reset --hard

Now you have no conflicts and have the version from GitHub, you only need to check it in (in SVN):

svn ci -m "Sync with GitHub"

Now both repositories are in sync and the version we kept is the one from GitHub.

Keeping the SVN files

Basically, it starts the same way:

cd ~/playground/mix/my_product_name
svn revert -R *

Now, you have the version from SVN. Now if you do a diff in GitHub, you’ll see the delta between svn and GitHub:

git diff

So all you have to do is to commit the changes and push them to GitHub:

git commit -a -m "Sync with SVN"
git push origin

After that you also have a conflict-free state with identical versions of the files in both repository. The only difference is that now GitHub has the same files as SVN (instead of the opposite in the previous case).

Propagating changes

Then I tested the following:

  1. Make a change in a Git working copy
  2. Commit and push to GitHub
  3. Pull it from GitHub into the mixed working copy
  4. Commit to the private SVN repo from the mixed working copy
  5. Update from the SVN repo to a pure svn working copy

The first step… Well, use vim, nano, notepad or anything else (guess you know how to edit a file).

Then commit and push to GitHub:

cd ~/playground/git/my_product_name
git commit -a -m "test"
git push origin

Then pull it from GitHub into the mixed working copy:

cd ~/playground/mix/my_product_name/
git pull origin

Then commit to the private SVN repo from the mixed working copy:

svn ci -m "test"

And finally, update from the SVN repo to a pure svn working copy:

cd ~/playground/svn/my_product_name
svn up
diff  ~/playground/git/my_product_name/my_modified_file ~/playground/svn/my_product_name/my_modified_file

You will then see that the file in the Git clone and in the SVN working copy are identical.

Google +

Linkedin

Subversion: Clone an SVN repository including the revision history

Posted on by hb

In order to run some test with svn and git, I needed to have a copy of an existing SVN repository to play around. Since I was pretty sure nobody was current accessing it, I could have gone for a copy of the existing repository files and a rename. But I wanted to do it in a clean way because I may need it again when I have less time to experiment.

Actually it was very easy. SVN provides two commands called dump and load. Dump exports a repository including the whole history i.e. the individual revisions. And load does the opposite, it imports all those revisions into a repository. So we need to do the following:

  1. Dump the repository to a file
  2. Create a new repository
  3. Load the dumped file to the new repository

So first the dump:

# svnadmin dump /var/svn-repos/kanban > /tmp/kanban.dump
* Dumped revision 0.
...
* Dumped revision 303.

So now, we’ve dumped all 304 revisions. Next create a new repository:

# svnadmin create /var/svn-repos/kanban_board

And load the dump in the new repository:

# svnadmin load /var/svn-repos/kanban_board < /tmp/kanban.dump
<<< Started new transaction, based on original revision 1
     * adding path : README.txt ... done.
...

------- Committed revision 1 >>>

...

<<< Started new transaction, based on original revision 303
     * editing path : styles/main_ci.css ... done.

------- Committed revision 303 >>>

Then I checked out from the new repository, which worked fine. Next test was to change something and check in. I got the following error message:

svn: E000013: Commit failed (details follow):
svn: E000013: Can't open file '/var/svn-repos/kanban_board/db/txn-current-lock': Permission denied

This basically means that I have the wrong permissiong on the db subdirectory of my repository:

# l /var/svn-repos/kanban_board/
total 24
drwxr-xr-x 2 root root 4096 Sep 23 18:52 conf
drwxr-sr-x 6 root root 4096 Sep 23 18:52 db
-r--r--r-- 1 root root    2 Sep 23 18:52 format
drwxr-xr-x 2 root root 4096 Sep 23 18:52 hooks
drwxr-xr-x 2 root root 4096 Sep 23 18:52 locks
-rw-r--r-- 1 root root  229 Sep 23 18:52 README.txt

It all belongs to the root user (the user I was logged in when creating the repository). So I just need to change it to the svn user. In my case I use the apache user and the svn user group so that I have access to the repository via a web interface as well as from the command line:

# chown -R www-data:svn /var/svn-repos/kanban_board/
# l /var/svn-repos/kanban_board/
total 28
drwxr-xr-x 2 www-data svn      4096 Sep 23 18:52 conf
drwxr-xr-x 3 www-data www-data 4096 Sep 23 19:02 dav
drwxr-sr-x 6 www-data svn      4096 Sep 23 19:02 db
-r--r--r-- 1 www-data svn         2 Sep 23 18:52 format
drwxr-xr-x 2 www-data svn      4096 Sep 23 18:52 hooks
drwxr-xr-x 2 www-data svn      4096 Sep 23 18:52 locks
-rw-r--r-- 1 www-data svn       229 Sep 23 18:52 README.txt

Note: the additional dav directory is there because I used websvn to check whether I could also see the repository in the web UI before listing the directory contents.

Now the commit works too and I have a clone of my original repository including the revision history !

Google +

Linkedin

How to use SVN 1.8 with Eclipse

Posted on by hb

In this post I’m using Subclipse. I am not too sure whether you’d have the same problem with Subversive or whether it can be fix in the same way. Also I am working on a Mac. Of course the actual solution to this problem is not Mac OS X specific but would also work with Linux. So if you are using Eclipse and Subversion, just ignore the Mac specifics (e.g. Homebrew) and keep reading.

I installed subversion 1.8 using Homebrew some time ago but Eclipse kept using the old svn version so I didn’t have to upgrade my working copies. Now I tried to update a working copy from the command line (it contains documents and not code. That’s why I didn’t do it in Eclipse) and saw that I hadn’t upgraded it yet:

$ svn up
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/Users/henribenoit/workspace/kanban'
is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects format 31). You need to upgrade the working copy first.

No big deal, I just upgraded all working copies:

$ svn upgrade

Now I could update them:

$ svn up
Updating '.':
At revision 303.

But now I couldn’t synchronize the working copies with the repository using Eclipse any more because eclipse was using the old svn version:

Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized.
An error occurred synchronizing /kanban: Error getting status for resource P/kanban org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
Error getting status for resource P/kanban org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).
org.apache.subversion.javahl.ClientException: svn: E155021: This client is too old to work with the working copy at
‘/Users/henribenoit/workspace/kanban’ (format ’31’).

Actually I had already installed subversion 1.8 but I didn’t install it with the Java language bindings (which I did when I installed svn 1.7). So to get a clean system, I removed svn:

$ brew remove subversion
Uninstalling /usr/local/Cellar/subversion/1.8.0...

And wanted to install it again with the java bindings and as universal binaries (with 32bits and 64bits support), but got an error message:

$ brew install --universal --java subversion
Error: subversion dependency serf not installed with:
--universal

So I had to remove serf so that it can be installed also as a universal binary:

$ brew remove serf
Uninstalling /usr/local/Cellar/serf/1.2.1...

And after serf, came sqlite:

$ brew install --universal --java subversion
Error: subversion dependency sqlite not installed with:
--universal
$ brew remove sqlite
Uninstalling /usr/local/Cellar/sqlite/3.8.0...

Now I could install subversion but it didn’t manage to create all the links because some links were left over from an older installation:

$ brew install --universal --java subversion
==> Installing subversion dependency: sqlite
...
==> Installing subversion dependency: serf
...
==> Installing subversion
...
Warning: Could not link subversion. Unlinking...
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
You can try again using `brew link subversion'

Possible conflicting files are:
...

It’s easy to fix by using the –overwrite option with brew link:

$ brew link --overwrite subversion
Linking /usr/local/Cellar/subversion/1.8.0... 108 symlinks created

Now svn 1.8 is installed properly (including the Java language binding for the Subversion API i.e. JavaHL). But when I tried in Eclipse to synchronize with an svn repository, I got the following error message:

Incompatible JavaHL library loaded. Subversion 1.7.x required.

This basically means that this version of JavaHL is not supported by the installed version of subclipse. In fact, the Subversion Wiki also gives you this info:

Subclipse Version SVN/JavaHL Version
1.10.x 1.8.x
1.8.x 1.7.x
1.6.x 1.6.x
1.4.x 1.5.x
1.2.x 1.4.x
1.0.x 1.4.x

You can check which version of Subclipse is installed in the “About Eclipse” menu item (click there on “Installation details” and search for Subclipse). If you see e.g. that Subclipse 1.8.1 is installed, the table tells you it will only work with svn 1.7. So we need a newer version of Subclipse. My first idea was to run an update in Eclipse. But it updated some other software but nothing related to subclipse. Then I notice that the update site I had used to install subclipse was: http://subclipse.tigris.org/update_1.8.x

This means that it will provide minor updates like 1.8.2, 1.8.3 and so on but no major update like the version 1.10.x that we need for svn 1.8. So I added a new update site for Subclipse 1.10.x: http://subclipse.tigris.org/update_1.10.x/

Then installed Sublipse 1.10.2 from this update site and after my sync with the svn repository was successful !

Google +

Linkedin

Eclipse and subversion: Failed to Load JavaHL Library

Posted on by hb

I haven’t used eclipse for some time (I recently spent more time upgrading, securing servers and writing shell scripts than actually programming). Now I wanted to check what the status of one of my latest projects was. But when I started Eclipse and synchronized with the subversion repository, I got the following error message:

Failed to load JavaHL Library.
These are the errors that were encountered:
no libsvnjavahl-1 in java.library.path
no svnjavahl-1 in java.library.path
no svnjavahl in java.library.path
java.library.path = .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java

I then searched for this library in the library path (was not sure it was really missing there), and found something:

$ ls -l /Library/Java/Extensions/libsvnjavahl-1.*
lrwxr-xr-x  1 root  admin  35 Mar 22  2013 /Library/Java/Extensions/libsvnjavahl-1.dylib -> /usr/local/lib/libsvnjavahl-1.dylib

I somehow remembered there were two files last time I had issues with the subversion integration. So I followed the linked and checked what was in /usr/local/lib:

$ ls -l /usr/local/lib/libsvnjavahl-1.*
lrwxr-xr-x  1 henribenoit  admin  53 Jul 24 23:35 /usr/local/lib/libsvnjavahl-1.0.dylib -> ../Cellar/subversion/1.7.8/lib/libsvnjavahl-1.0.dylib
lrwxr-xr-x  1 henribenoit  admin  47 Jul 24 23:35 /usr/local/lib/libsvnjavahl-1.a -> ../Cellar/subversion/1.7.8/lib/libsvnjavahl-1.a
lrwxr-xr-x  1 henribenoit  admin  51 Jul 24 23:35 /usr/local/lib/libsvnjavahl-1.dylib -> ../Cellar/subversion/1.7.8/lib/libsvnjavahl-1.dylib
lrwxr-xr-x  1 henribenoit  admin  52 Jul 24 23:35 /usr/local/lib/libsvnjavahl-1.jnilib -> ../Cellar/subversion/1.7.8/lib/libsvnjavahl-1.jnilib

So I have a link to the .dylib file in /Library/Java/Extensions/ but I miss a link to the .jnilib. Easy to fix:

$ ln -s /usr/local/lib/libsvnjavahl-1.jnilib /Library/Java/Extensions/libsvnjavahl-1.jnilib

After that I could syncronize with the svn repository in Eclipse !

Another solution I tried is to move away from the jni based svn client adapter and use the pure Java SVNKit adapter. To change this setting, go to the Eclipse preferences and write svn in the filter:

SVN interface client

I’ve resized the window to only show the relevant setting, this dialog actually has many more settings. In the displayed select box you can choose between JavaHL (JNI) and SVNKit (Pure Java). If you use SVNKit, you don’t need to have access to the native library shown above.

When it comes to choosing between JavaHL and SVNKit: When a new version of subversion is available, JavaHL is usually available earlier. So you can upgrade earlier. But it is often more difficult to install and integrate than SVNKit.

Google +

Linkedin

Install svn (subversion) on Mac OS X

Posted on by hb

I wrote an article about a year ago, about svn (Subversion) being missing in Mountain Lion (10.8) and how to install it manually. Since then, I’ve got a new mac and have used myself this post to install it on the new machine. Since then there has also been new versions of subversion but unfortunately all my software are not compatible with it. So I’ve been looking into this topic again and wanted to share.

Another way to install svn on mac is to use a ditribution package from wandisco. They are available here. Do not use the packages on CollabNet which are outdated.
Unzip the .pkg file and double click on it and follow the instructions to have it installed.

I still like it better with Homebrew since it makes it very easy to upgrade the packages and switch between packages.

To find out the version currently active with Homebrew:

brew info subversion

You can check the versions of subversion which are available using:

brew update
brew versions subversion

This will return multiple lines, one per version, each containing a version number and the checkout command e.g.:

1.8.1 git checkout 55577bb Library/Formula/subversion.rb

Choose the version you want to install e.g. here 1.8.1, switch Homebrew’s prefix,checkout the package and install it:

cd `brew --prefix`
git checkout 55577bb Library/Formula/subversion.rb
brew install subversion

Then reset the formula:

git checkout -- Library/Formula/subversion.rb

You can then switch between versions using brew switch (which updates the symlink in /usr/local/bin to the specified formula version in the Homebrew cellar) e.g.:

brew switch subversion 1.7.3

Of course mechanism can be used for any other Homebrew package.

If you get errors in XCode while accessing working copies created with a newer version, you might need to link the newer version into XCode by doing the following:

  • Create a backup directory for the svn binaries currently used by XCode
  • Moving the current binaries to the backup folder
  • Linking the binaries of the new version installed with Homebrew into Xcode (as a replacement for the moved ones)

You can do that by executing the following and replacing 1.7.4 by the actual subversion version you want to use in XCode:

mkdir /Applications/Xcode.app/Contents/Developer/usr/bin/save
mv /Applications/Xcode.app/Contents/Developer/usr/bin/svn* /Applications/Xcode.app/Contents/Developer/usr/bin/save/
ln -s /usr/local/Cellar/subversion/1.7.4/bin/svn* /Applications/Xcode.app/Contents/Developer/usr/bin/

Note that you can also use Homebrew-versions instead. It provides multiple formulas for different versions of existing packages e.g. subversion1.6 and subversion1.7. If you use it, you will of course not be able to upgrade from 1.7 to 1.8 but only from 1.7.2 to 1.7.3 but it’s maybe what you are after…

You can install from Homebrew-versions using:

brew install https://raw.github.com/Homebrew/homebrew-versions/master/subversion17.rb

You’ll notice that Homebrew-versions only has packages for subversion 1.6 and 1.7. But I guess 1.8 should come soon.

So there are quite a few ways to install subversion on your mac and handle different versions. The one I like best is still just installing it with Homebrew and switching to the one I use most. The other versions are still available by other switching to a particular version as shown above or by using the svn command from a particular version in the Homebrew Cellar e.g.

/usr/local/Cellar/subversion/1.7.4/svn

Google +

Linkedin

Mac OS X: SVN (Subversion) missing in Mountain Lion (10.8)

Posted on by hb

After upgrading to Mountain Lion, I realized that subversion (svn) was missing. Since I happened to install a new version of eclipse I first thought the problem was with my eclipse install but after wasting way too much time trying to fix it in eclipse I realized my problem was somewhere else…

So here’s what I did to fix it. SVN is part of the Command Line Tools. To install them go to Downloads for Apple Developers. This requires an Apple Developer ID. Getting one is free and only requires an Apple ID which you should all already have.
There select Command Line Tools (OS X Mountain Lion) and download the DMG file (it’s about 110 MB). Then open the DMG file, double click on Command Line Tools (Mountain Lion).mpkg, just keep clicking Continue / Agree / Install.

An alternative is to install Xcode. You can download it from the Mac App Store. Once Xcode is installed, you can go the Preferences > Downloads > Command Line Tools and install them.
Xcode install command line toolsThe downside of this method is that you have to install Xcode which is a waste of space (1.5 GB download and 3.3 GB install) unless you develop for Mac OS X or iOS. But if like me you have Xcode installed anyway…

Once you’ve installed the Command Line Tools, you can check whether SVN is installed and whether you have the right version (1.6.18) opening a Terminal and typing the following:

svn --version
svn, version 1.6.18 (r1303927)
   compiled Jun 15 2012, 19:07:58

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

That’s it !

Update: Another way is to use Homebrew or MacPorts.

With Homebrew installed, open a Terminal window and type the following:

brew install subversion

If you get the following error:

curl: (22) The requested URL returned error: 503
Error: Download failed: http://pkg-config.freedesktop.org/releases/pkg-config-0.25.tar.gz

You will need to type the following:

brew edit pkg-config

The replace the two lines with url and md5 by:

  url 'http://sourceforge.net/projects/buluoos/files/0.4/src/pkg-config-0.25.tar.gz/download?use_mirror=garr'
  md5 'a3270bab3f4b69b7dc6dbdacbcae9745'
  version '0.25'

Save and rerun the install of subversion. If you get the following error message:

curl: (22) The requested URL returned error: 404
Error: Download failed: http://www.apache.org/dyn/closer.cgi?path=subversion/subversion-1.7.4.tar.bz2

This means that your HomeBrew installation should be updated. It should fetch subversion 1.7.5 instead of 1.7.4. You can update it with the following command:

brew update

Then rerun the subversion install.

If the installation of subversion or an upgrade to a newer version gets stuck (this happens to me every time), with the following last line written to the console:

==> make

Just kill it with CTRL-C and restart it. In my case, it always gets stuck for hours the first time and works the second time…

After the install, you might see when running svn –version that it doesn’t say 1.7.5. This is because the new version is installed in /usr/local/bin and there is an older version in /usr/bin. If your PATH looks like this:

echo $PATH
/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/X11/bin

Then you’ll see the svn program in /usr/bin because it is before the /usr/local/bin in PATH. So you need to update your PATH so that /usr/local/bin comes before /usr/bin:

vi ~/.profile

There add /usr/local/bin:

...
export PATH=/usr/local/bin:/opt/local/bin:/opt/local/sbin:$PATH
...

If you want to have a subversion integration in Eclipse, you’ll need the java bindings. To install them using Homebrew execute the following:

brew install --universal --java subversion

Universal means it will install both 32 and 64bit version (without this the java bindings will most probably not work fine). And the Java option tells Homebrew to additionally install the Java bindings.

If you’ve already installed subversion using Homebrew without the java bindings, you can just uninstall it and reinstall it with the bindings:

brew uninstall subversion
brew install --universal --java subversion

If you get messages saying you need to first remove some packages, remove them, they will be reinstalled when installing subversion, e.g. I had to remove neon and serf:

brew rm neon serf

After installing with the bindings, there will be some instructions about links to be created. It’s important to create these links. On my machine and with subversion 1.7.7, it said:

You may need to link the Java bindings into the Java Extensions folder:
  sudo mkdir -p /Library/Java/Extensions
  sudo ln -s /usr/local/lib/libsvnjavahl-1.dylib /Library/Java/Extensions/libsvnjavahl-1.dylib

Unfortunately, on my machine the Eclipse integration still didn’t work… Until I noticed the instructed linked was not completely right:

ls -l /Library/Java/Extensions/
total 16
drwxrwxr-x  4 root  admin  136 Nov 30 21:36 .
drwxr-xr-x  5 root  wheel  170 Oct 25 22:33 ..
lrwxr-xr-x  1 root  admin   35 Nov 30 21:36 libsvnjavahl-1.dylib -> /usr/local/lib/libsvnjavahl-1.dylib
lrwxr-xr-x  1 root  admin   40 Dec 21  2011 libsvnjavahl-1.jnilib -> /opt/subversion/lib/libsvnjavahl-1.dylib

So basically the link was created with the wrong them. So just had to do the following to solve the problem:

cd /Library/Java/Extensions/
mv libsvnjavahl-1.jnilib libsvnjavahl-1.jnilib.sav
mv libsvnjavahl-1.dylib libsvnjavahl-1.jnilib

If like Julio, you have some error messages related to libpq.5.dylib having a wrong architecture, you can try the following:

find / -name "libpq.5.dylib"

This will find all occurrences of this library. On my machine, it found it there:

/Applications/AMPPS/extra/lib/libpq.5.dylib
/Applications/MAMP/Library/pg/lib/libpq.5.dylib
/Applications/MAMP_2012-08-11_23-20-34/Library/pg/lib/libpq.5.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/libpq.5.dylib
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/libpq.5.dylib
/usr/lib/libpq.5.dylib
/usr/local/php5/lib/libpq.5.dylib

Checking the one in /usr/lib, you see that it’s a 64bit only library:

file /usr/lib/libpq.5.dylib
/usr/lib/libpq.5.dylib: Mach-O 64-bit dynamically linked shared library x86_64

But the php library was both 32 and 64bit:

file /usr/local/php5/lib/libpq.5.dylib
/usr/local/php5/lib/libpq.5.dylib: Mach-O universal binary with 4 architectures
/usr/local/php5/lib/libpq.5.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
/usr/local/php5/lib/libpq.5.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/usr/local/php5/lib/libpq.5.dylib (for architecture ppc7400):	Mach-O dynamically linked shared library ppc
/usr/local/php5/lib/libpq.5.dylib (for architecture ppc64):	Mach-O 64-bit dynamically linked shared library ppc64

So you probably only need to replace the one in /usr/lib by this one:

sudo mv /usr/lib/libpq.5.dylib /usr/lib/libpq.5.dylib.only_64
sudo cp /usr/local/php5/lib/libpq.5.dylib /usr/lib/libpq.5.dylib

If you still have problems when integrating svn with eclipse, please a have look at this post.

Note that I’ve written a new post to show how to handle multiple subversion version using brew.

Google +

Linkedin