Posted At : January 4, 2007 12:14 PM
5 Comments
WARNING: if a Subversion 1.4 client encounters a pre-1.4 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, you need to be careful about which version you use in which working copy, to avoid accidentally upgrading the working copy format. This "auto upgrade" feature, however, does not occur with the new repository format.
Here is a small howto on installing SVN 1.4 on Ubuntu as there are no packages for Edgy yet (if ever).
Download the following two files:
Extract the files on your machine and configure:
Compile the application:
Install the application:
If you get an earlier version then you may need to close and reopen your terminal to update the path info.
5 Comments
If you built Subversion with JavaHL support then you could use the JavaHL library within Subclipse, which I personally prefer. Building is just a matter of adding some flags to the configure step. See our FAQ:
http://subclipse.tigris.org/faq.html#build-javahl
Also, in the steps you performed, you will not have SSL support because you did not pass --enable-ssl to configure. I could be wrong, maybe configure is smart enough to detect it itself. If you run svn version without the --quiet switch you would see the ra methods you have built. I am guessing you will not see https included in the list.
Hi Mark,
Is my understanding correct: with JavaHL subclipse will use the installed version of svn instead of relying on it's on pure java version. This would certainly avoid this problem.
Is that the only reason for your preference or are there other reasons too?
You are right about the enable ssl switch - I'll update the instructions.
If you build the JavaHL library and take the necessary steps so that it can be found via a JNI call, then you can set your preferences so that JavaHL is the client interface that is used.
Speaking generally, there are no advantages to one interface versus the other, but there are specific scenarios where one can be a better option. For example, SVNKit uses Java for all of its http communication. By default, Java cannot support the SSL of most sites because of encryption export standards. You can update the JCE to a higher strength, but even then I have found it cannot handle the certs from some sites. That is just an example, there are cases where SVNKit has better options too.
Personally, I just prefer to be using the same Subversion code that the command line uses as you know that multiple clients will then all behave the same.
Hi Mark
What are "the necessary steps so that it can be found via a JNI call" - can you point me to some instructions on this?
Also - I tried to build it will --enable-ssl and it doesn't work - I presume I need the openssl source or similar but can't find any documentation on this - any pointers?
Thanks for you feedback.
Cheers,
Mark
There is an FAQ for that right after the last one I referenced. Basically, JNI looks in java.library.path which is set for LD_LIBRARY_PATH which on most Linux systems now is not set or empty. I usually create a shell script that I use to start Eclipse. Something like this:
export LD_LIBRARY_PATH=/usr/local/lib:.
./eclipse
As for SSL, yes you need OpenSSL installed (odd that it wouldn't be) and normally configure should just detect it and setup the necessary linkage.