9

While I can easily find the binaries for the latest version of subversion (1.6) I can't find the binaries for Ubuntu (or Debian).

The download page at tigris.org suggest to use the command:

apt-get install subversion

but as you can experience this will install up to the version 1.5.4 (at the time of writing May 6, 2009).

This isn't a nice thing because many working copies that I share with Windows are automatically updated to 1.6 by TortoiseSVN.

Improve this question
2

7 Answers 7

Reset to default
12

Here is an APT repository with Subversion 1.6 binary packages for Ubuntu 8.04 through 9.10: https://launchpad.net/~anders-kaseorg/+archive/subversion-1.6

Improve this answer
2
  • broken, complains about no public keys
    – Jay
    Jul 16, 2009 at 2:32
  • 1
    open the link in your browser you'll find the key on that page.
    – pvgoddijn
    Jul 20, 2009 at 13:56
10

I solved it with these repositories:

deb http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu intrepid main
deb-src http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu intrepid main

Improve this answer
3
  • Will this Ubuntu repository also work safely on Debian stable? I'm particularly looking for the Apache2 svn module since I want to upgrade my svn server to 1.6.
    – Martijn Heemels
    Aug 6, 2009 at 7:52
  • Where are the PGP keys for the packages? I cannot find them.
    – migu
    Aug 11, 2009 at 14:15
  • Follow the instructions at launchpad.net/~anders-kaseorg/%2Barchive/subversion-1.6l to install the package. Recall that you can authenticate the PPA in Ubuntu using the signing key (from the site: 1024R/413576CB). In this case, the terminal command to add the key is: sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 413576CB
    – Paul Lammertsma
    Oct 23, 2009 at 9:28
6

You can find a debian package for subversion 1.6 in the experimental repositories from debian at http://packages.debian.org/experimental/subversion.

Having said that you would probably be alright working with version 1.5.4 from the ubuntu repositories, if the svn server you are using isn't running 1.6 you won't be able to use any of the new features in the client anyway.

If I was you I would first try to use the version in the repositories before installing it from a third party as you may find that it does work for you and it will make your life easier when it comes to updating subversion in the long run.

Improve this answer
4
  • 1
    Note that it may be necessary to rebuild the experimental packages from source (using dpkg-buildpackage), as they may be built against a newer version of glibc.
    – bdonlan
    May 6, 2009 at 22:09
  • 1
    Thanks but this method will require the installation of many other experimental dependencies that I don't want install.
    – Andrea Francia
    May 19, 2009 at 17:31
  • Do you really think that using an "experimental" package that will upgrade also the Apache HTTPD to the "experimental" version notwithstanding I need only the client will make my life easier?
    – Andrea Francia
    Jul 27, 2009 at 21:28
  • Third party? The CollabNet are the creators of Subversion the piece of software that I need.
    – Andrea Francia
    Jul 27, 2009 at 21:32
4

Add these two lines to your /etc/apt/sources.list:

deb http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu hardy main 
deb-src http://ppa.launchpad.net/anders-kaseorg/subversion-1.6/ubuntu hardy main

Get Anders key:

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 413576CB

Update:

sudo apt-get update

Upgrade or Install:

sudo apt-get upgrade
sudo apt-get install subversion

(Via GVS)

Improve this answer
2

You can find certified binaries here, now: http://www.wandisco.com/subversion/os/downloads?type=ubuntu910

The script will setup a repository for you, so you will keep on getting updates.

Improve this answer
2

Solved! Here the solution.

From the CollabNet download page download the binaries for Red Hat. Then use alien for installing it, for example:

$ sudo apt-get install alien
$ sudo alien CollabNetSubversion-client-1.6.2-1.i386.rpm
$ sudo dpkg -i collabnetsubversion-client_1.6.2-2_i386.deb

Beware that the command is installed under /opt/CollabNet_Subversion/bin/svn not in /usr/bin/svn. So after that simply put this line in your .bashrc:

export PATH="/opt/CollabNet_Subversion/bin:$PATH"
Improve this answer
5
  • 1
    Don't do that, use the packages from experimental.
    – Torsten Marek
    May 28, 2009 at 23:33
  • 1
    @Marek: Why are you suggesting this? First of all I'm scared by the "experimental" word :) ... And in any case doing that it would install many other experimental revision of other important packages (like Apache).
    – Andrea Francia
    May 29, 2009 at 10:14
  • Due to the various distributions setting up their systems differently packages from other distributions can mess up your system. Alien isn't smart enough to pick up on these difference and adjust accordingly.
    – Mike Lowen
    May 30, 2009 at 4:37
  • @mlowen: it's generally true but, please, note that in this case the 'aliened' package is from Collabnet and not from another distribution and that the installation of the subversion package from Collabnet is quite independent from the rest of the system: in fact nothing is integrated and all files are under /opt/CollabNet_Subversion. In this case there is nothing to adjust because nothing is integrated. This is not a issue for my case.
    – Andrea Francia
    Jun 2, 2009 at 20:54
  • Using alien to get a package in debian should be the ultimate last resource.
    – feniix
    Jul 8, 2010 at 16:42
0

You don't need the 1.6 version to work with your Windows working copies. SVN is clever enough to recognise the features provided by clients, and only allow those features through - so your 1.5.4 client can connect to your 1.6 server without any problem; as can your Windows 1.6 client.

The only time you'll have problems here is if you're using 2 clients with a single working copy - ie your Windows and Linux clients both commit and update a single, shared directory. Such an arrangement is a bad idea anyway, you'll have all kinds of problems even without counting EOL differences. If you have such a situation, checkout a new WC, so you have one for Linux and another for Windows.

Improve this answer
4
  • 1
    -1 for two reasons: 2. I regularly works with working directories shared between Windows and Linux and I never found any problem related to EOL differences. If you don't use special properties Subversion simply leaves the EOL character(s) that it found. Any decent Linux and Windows editor can handle both EOL styles. 1. As I specified I need 1.6 because I want to use the updated version of TortoiseSVN which uses the 1.6 subversion libraries.
    – Andrea Francia
    May 9, 2009 at 19:58
  • well, it wasn't that clear that you had a single WC for both OS. I doubt that's a common case.
    – gbjbaanb
    May 9, 2009 at 22:56
  • Sharing a working copy between Windows and Linux has in the past been considered a Wrong Thing To Do. Not sure what the latest is now, but this post says it mostly comes down to EOL issues now: subversion.open.collab.net/ds/… I'd still say that sharing a working copy is an unnecessary way to work, given the opportunities for other workflows that Subversion makes possible.
    – Craig McQueen
    Jun 29, 2009 at 0:13
  • you can also have multiple client on the same (linux) platform. at least this is the case with eclipse (subclipse-plugin)
    – pvgoddijn
    Jul 20, 2009 at 13:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.