Back in July 2009, I blogged about My love-hate with SVN, Part 6: Installation Ease Of Use. With Helios just around the corner, I wanted to produce an updated repo for use with the latest & greatest Eclipse 3.6.
Now the <p2.mirror/> script will fetch and use Ant-Contrib automatically.
Here's the updated 15M update site zip, which includes the following:
Subversive 0.7.9Any problems, please report them in bug 284077.
SVN Connector 2.2.2
SVNKit 1.3.3
JNA 3.2.3
ECF 3.1.0
It's true that the shoemaker's children often go shoeless; so to my little Sourceforge project, Beyond CVS/SVN - maintained tirelessly over the years by Chris Callendar - has had to wait *years* to finally get its own update site.
Sad, I know. But thanks to a recent breakthough in being able to insert associate sites into p2 repo metadata, you can now install Beyond CVS/SVN without having to hunt down Subclipse or Subversive's update sites.
Here's the new site: http://beyondcvs.sourceforge.net/update/0.8.x. If you point Eclipse at it, you can install the features therein. If you point a browser at it, you can see instructions for how to do the install. And if you want an offline install, here's the zip: org.eclipse.externaltools-Update-0.8.9.v201003051612.zip (README).
SVN metadata appears when searching
Why would anyone ever want to see .svn folders and their children in Eclipse? If they're hidden from the Package Explorer, why can't I hide them from a Search? And if I did a naive find and replace, wouldn't this corrupt the metadata and prevent me from committing the update to the repo?
If you've inherited code where someone has accidentally committed *.class files, here's how you can find those bin/ folders, wipe them out, and hopefully never see them in the Synchronize view again.
Sure, you could use Team > Add to svn:ignore... on a file or Team > Set Property... on a folder in Eclipse using Subversive, but this is faster and less clickity-click.
for d in $(find -maxdepth 1 -mindepth 1 -type d ~/workspace/ -name "org.eclipse.*"); do pushd $d svn up svn propset svn:ignore "bin bin/*" . svn propget svn:ignore . svn propset svn:ignore "*.class */*.class **/*.class" bin svn propget svn:ignore bin cd bin rm -fr * svn delete org svn delete model # find other deleteables with `svn status` cd .. svn ci -m "svn:ignore" popd done
For months I've been annoyed by the fact that installation of Subversive (or Subclipse) requires fetching features and plugins from 3 or more update sites. No more!
Today, as an exercise to learn how to use the <p2.mirror/> task and provide a reproduceable, offline way to get Subversive into a virtual machine, I've created an update site zip, complete with site.xml and p2 metadata, which can be used to install Subversive from a single source. Here's the Ant script if you'd like to try this at home.
Because let's be real: you can only complain so long before it's time to roll up your sleeves and pitch in, right? That's how open source survives - thanks to people who care enough to complain AND care enough to help.
Here's the 13M update site zip, which includes the following:
Subversive 0.7.8
SVN Connector 2.2.1
SVNKit 1.2.3
JNA 3.0.9
ECF 3.0.0
Any problems, please report them in bug 284077.
Finally figured out how to make Eclipse 3.5 play nicely on Fedora 11 w/ Subversion, and I owe this bit of knowledge to our new MacPro. *sigh*
I also owe a great deal of gratitude to Cloudsmith for providing their Cloudsmith Galileo+ repository, which includes these features:
I still wish the version numbers would better align, in that I have to install the SVN Team Provider v0.7.8 with the SVN Connector v2.2.0 and the SVNKit 1.3.0 implementation v2.2.0 to make all this work with Subversion 1.6. Oof.
A month ago a very large package arrived in the mail: my first MacPro server. I at once fell in love with the case design - clean, simple, and dead-easy to take apart in order to add more drives and RAM. However, that's where the love boat ran aground.
To say it's been a gradual learning curve would be an understatement. Here are a few things I've learned over the past month of dealing with Mac hardware and OS, as well as retraining my fingers to use Mac keyboard bindings (META = Apple Key or Windows Key, depending on your keyboard).
apt-get and Gentoo's emerge, respectively. Once XCode and DarwinPorts are installed, you can port install vpnc (to fetch deps and compile on the fly) or apt-get install curl (to fetch deps and install).
/efi/refit/refit.conf approximately replaces /boot/grub/menu.lst at least as far as picking what partition to default-boot and how long to wait
/System/Library/Frameworks/JavaVM.framework/Home instead of /opt/ or /usr/lib/jvm/java
However, the version of Subversion available via Fink doesn't work with projects checked out using Eclipse - seems that the commandline client (Subversion 1.4.4) and Subversive with SVNKit (SVN 1.6.1 w/ SVNKit 1.3.0.beta.r5741) are not compatible:svn: This client is too old to work with working copy '.'; please get a newer Subversion client. Using DarwinPorts to update the subversive client to 1.6.3 fixed this issue, but installed it into a different path (/opt/local/bininstead of/sw/binor/usr/bin).
Installing Subclipse w/ JavaHL (aka CollabNet Subversion)
- Download CollabNet Subversion for your operating system (Linux, Windows, MacOS X). This provides the JavaHL layer so that Subclipse can talk to SVN repos using pure Java (but not SVNKit). Install it.
- Download Eclipse 3.4.1 (or Fedora Eclipse). Start it up, making sure to pass in
-Djava.library.path=/opt/CollabNet_Subversion/lib(linux only).- Help > Software Updates... > Available Software > Manage Sites... > Add... > http://subclipse.tigris.org/update_1.4.x
- Install the whole site. Restart when prompted.
- Window > Preferences > Team > SVN > SVN Interface > Client > JavaHL (JNI)
Well, I feel I've been remiss in ranting about Subclipse. Turns out a fresh Eclipse + a fresh install (and a lot of trial and error / googling has fixed things.
You have not exactly given us a chance to help you with your Subclipse issues.Mark, you're right, Subclipse does work -- it's just not the most straightforward thing to install. And when it breaks suddenly and for apparently no reason, losing hours of productivity to fighting w/ source control instead of writing and committing code, it's VERY frustrating, especially considering that Eclipse's CVS support Just. Works.
Does the JavaHL library exist in the folder you pointed to?Well, given the wiki doesn't actually say what file(s) are supposed to be there, I had to guess. I have
/usr/share/java/svnkit-javahl-1.1.4.jar and /usr/share/java/svnkit-javahl.jar (a symlink to the previous). Is that what Subclipse / Subversive are looking for? No idea.
Do the preferences say "Not available"?They do. After much surfing, googling, testing, registering to download, waiting for a password, cursing, downloading and
rpm -i ... I finally figured out that all I needed to do was get CollabNet Subversion Command-Line Client v1.5.4 (for Red Hat Linux), and (as noted in the wiki), add -Djava.library.path=/opt/CollabNet_Subversion/lib to my Eclipse startup. Could you save others this search by linking to the downloads page from the wiki? Or even linking to it from the Downloads page??
I think somehow an old version of their JAR is being loaded by your Eclipse and not the one in their plugin. Do you have their JAR installed in your Java extensions folder or something?Reinstalling Eclipse and purging some jars of unknown pedigree & version seems to have worked. I have svnkit 1.1.4 in the above folder (
/usr/share/java), and org.tmatesoft.svnkit_1.2.0.4949 in a linked folder in my dropins/.
Finally, as to your History error, Subclipse does not have this problem, but I know the cause. Your history view is setup to "Show Merged Revisions". I would assume that Subversive exposes this as an option in the UI that you can turn off. That is what we do in Subclipse.I expected to find this as an option under Window > Preferences -- some digging showed me that, no, it's under the view's menu > Include Merged Revisions. Thanks for the tip!
Anyway, we also catch that exception when talking to older Subversion servers and just make the request again without asking for the merged revisions. If you have not already filed a bug report with Subversive you probably should.Good idea -- see bug 257669. I just want something that will work, won't crash Eclipse, won't freeze up during an update, won't leave dozens of "not really there" files in my Synch view (that magically disappear when I click the 'collapse all' button in the view), won't throw errors when I try to look at file histories.
So, for the moment, I'm back to Subclipse. I've upped the permgen and heap for Eclipse to 400M and things are working again. Seems large projects + SVN = crashing/freezing/OOM errors. Maybe JavaHL won't be so greedy? We shall see.
The love-hate continues...
Show History operation failed
*** Show History svn: Retrieval of mergeinfo unsupported by 'https://svn.jboss.org/repos/devstudio/trunk/releng/org.jboss.ide.eclipse.releng/hudson/build.sh' *** Error (took 00:00.743) *** Show History svn: Retrieval of mergeinfo unsupported by 'https://svn.jboss.org/repos/devstudio/trunk/releng/org.jboss.ide.eclipse.releng/hudson/build.sh' *** Error (took 00:00.795)
This is particularly fun because the error comes up twice, and keeps coming up as long as you have the History view shown. Solution? Time to switch back to Subclipse? No, I tried that, and despite adding -Djava.library.path=/usr/share/java to my Eclipse startup, I still can't use Subclipse anymore.
Oh, well... there's always kdesvn:
Since joining JBoss, a division of Red Hat, I've gotten to know the foibles of SVN rather intimately. Here are my two favourites, both encountered this week:
This client is too old to work with working copy; please get a newer Subversion client.
Problems reported while synchronizing SVNStatusSubscriber. 2 of 3 resources were synchronized. An error occurred synchronizing /devstudio-workspace: Error getting status for resource P/devstudio-workspace org.tigris.subversion.javahl.ClientException: svn: This client is too old to work with working copy; please get a newer Subversion client
This happens if you use SVN 1.5.4 and Subclipse 1.4.6 with SVNKit & JavaHL plugins. Solution? Switch to Subversive 0.7.5, or follow this advice (so I'm told, I haven't tried yet).
(from /var/log/yum.log) Nov 27 19:51:47 Installed: subversion-javahl-1.5.4-3.i386
[java] fetchElement:
[java] #
[java] # An unexpected error has been detected by Java Runtime Environment:
[java] #
[java] # SIGSEGV (0xb) at pc=0x05984ec5, pid=24986, tid=3086982032
[java] #
[java] # Java VM: Java HotSpot(TM) Server VM (11.0-b15 mixed mode linux-x86)
[java] # Problematic frame:
[java] # C [libapr-1.so.0+0x1fec5] apr_threadkey_private_get+0x15
[java] #
[java] # An error report file with more information is saved as:
[java] # /opt/public/jbt-jbds/nightly-20081128-0002/org.jboss.ide.eclipse.
releng/builders/hs_err_pid24986.log
[java] #
[java] # If you would like to submit a bug report, please visit:
[java] # http://java.sun.com/webapps/bugreport/crash.jsp
[java] # The crash happened outside the Java Virtual Machine in native code.
[java] # See problematic frame for where to report the bug.
[java] #
[java] Java Result: 134(from /var/log/yum.log) Dec 02 11:19:23 Erased: subversion-javahl
And now it works again!
Contact:: Nick Boldt:: Toronto + Halifax, Canada Productization, Containers & Operators:: Red Hat CodeReady Workspaces |
  |
|
|