SVN on Eclipse using JavaHL

If you're finding that Subversion is not working with Eclipse due to an error such as:

unable to load default svn client

Visit Collabnet and download the latest Universal Subversion Binaries. I searched for a direct link to get software using the Eclipse software utility, but found nothing as useful as the repository on Collabnet. Unfortunately you have to register first, but it's a quick form.

After you install the binaries, you should be able to verify that JavaHL is working by visiting Eclipse>Preferences>Team>SVN, on the drop-down for SVN interface client.

Eclipse Galileo 3.5 to Helios 3.6

I did Windows for a long time. And I'm still ok with it (though I stopped upgrading at XP SP2). Just the same, I'm all in with Mac for the past couple of years. The wherefore comes down to OS X, and more specifically, Unix. Can't beat having an underlying layer of open source OS!

I'm upgrading Eclipse today. I had announced with great fanfare the coming of Eclipse Galileo, but Helios found me focused on other things, so I'm stepping up the SDK to 3.6 now. On the Windows/Mac front, I prefer the small install and configuration footprint of unix apps vs the windows registry. Power Windows users may opine otherwise, but I find the modularity of apps on the mac to be quite painless.

That said, I'm opting not for a clean install of Eclipse 3.6, but rather an upgrade from 3.5 using the software updates dialog. A little background, I use both Flash Builder and Eclipse on my MacBook, the former for AS3 and Eclipse for JS, PHP, Python, basically 'everything else'. I have added Subversive SVN to FB and it works great, and with the possible exception of mylyn in the future, I plan to keep FB in quarantine. (update: broke my own rule there, I added eGit to FB and it is flawless.)

This is just a safety, as I have had issues with other FB installs going off the rails when too many open-source libraries are added to the SDK. It can be a real train wreck when this happens, especially if you're facing a killer deadline. For the record, any deficiencies with Eclipse as a platform are simply the small and acceptable dark side to a robust and maverick developer community. So I keep FB static and use Eclipse as my test lab.

As for the SDK upgrade, it worked great. Here is a simple FAQ from Eclipse to follow. When the dialog presents you with a list of available upgrades, choose only those listed as 3.6. Better not to upgrade too many things all at once.

This is part of a larger operation which I will also post about. Namely, getting a JS/PHP/Git environment up and running within the Eclipse SDK. I've worked with TextMate thus far and will sing its charms, however, I've used Eclipse long enough to love what it does, so developing in a fully Integrated DE is my goal.

A Morsel on Flash Professional Projects in Flash Builder

Flash Builder is so very great to use. Such a time saver for the stuff I work on, especially in conjunction with subversion. Having a repository view of a remote SVN server, being able to update and commit, not to mention the ease of 'diffing' in the Eclipse SDK. Best thing ever.

Lock down FB and SVN and you will find varying project types to choose from: Flex Project, Flex Library Project, or Flash Professional Project. Please join me in considering the good and bad of the Flash Professional Project.

Here are the things I like and don't like about managing a Flash Professional Project from FB.

The Likes:

• The .project configuration file
• can be saved to SVN, so you can open all your resources quickly at later date
• allows you to select .as files from within Flash Pro and have them open in FB for a better coding experience ( still better even thoughh Flash Pro now completes code)
  

The Dislikes:

• The .project configuration file
• because collaborators with whom you share the Flash Professional Project, since the .project file is generally only usable in one particular configuration, will find it distracting
  
• Two environments (FB and Flash Pro) means 2x the path configuration. Yes, you have to path to libraries and swcs twice. Once in FB, and once in Flash Pro.
• Frequent quickly appearing and then disappearing phantom publishing panels, due to the need for FB to remain synchronized with Flash Builder. I'm on Mac and this is one of the more disturbing issues.
• The fact that you must create and save a .FLA as a precursor to starting a new Flash Professional Project, then associate the .FLA with the new Project, and then add the new document class back to the .FLA. Far better to have the .FLA generated through FB and configured according to initial project values.

Seems like the nays have it this time. I find it works better to use subclipse to manage FLAs without converting them into Flash Professional Projects. The only tiny caveat to this approach is that you must open the associated .as files directly from FB rather than via Flash Pro.

It remains to be seen what Flash Builder "Burrito" adds to this mix.

Subversive SVN for Eclipse is Troubled

Kind of, yes. What is so terrible, in fact, is the great number of pitfalls waiting to be uncovered.

You can hope for no whammies but you will most likely trip the eclipse-subversive trap along the way to configuring a working setup. Problem is, JavaHL and SVNKit don't tend to work out of the box. You have to hunt them down from at least 2 locations, and doing so often results in installation conflicts.

If you are using SVNKit, it is because your svn over ssh is password-protected. If you go this route and don't mind the confusion of double passwords with very poor contextual info, you may be almost home free. The subversive interface interchanges the exact same control panel for both ssh and svn credentials, mediated by what is a very unreliable drop down for context. The combination is tricky at best.

If you choose JavaHL, it is most likely in order to configure an ssh key to engage your repository. SSH keys require JavaHL be enabled rather than SVNKit. You will be dismayed to discover how difficult it is to properly resolve a file key through the subversive interface. In all likelihood, it will fail silently.

To minimize the difficuly, the following is highly recommended:
Use SVNKit and password authentication for SSH
When the duplicate credentials dialogs mock you, just keep trying combinations based on your notes.

Good luck.

Update:
Subversive is easier to manage if your ssh and svn un/pw are the same.
It would be great if subversive could remember it if the SSH port is not 22. If it is not, you will have to input it every freaking time. Or!:
Visit Eclipse > Preferences > Team > SVN > Properties Configuration > Custom properties and add

SVN_SSH = ssh -p [portnum]

If you fail to synchronize, do over and over again. My subversive setup sometimes fails to synch 3-4 times before finally consenting.

Setting up Post-Hooks for Subversion

The publicly available subversion book at svnbook.red-bean.com is both concise and comprehensive. It can help you deftly steer a subversion server in any way your inner administrator hankers to go.

I found subversion helpful in tracking versions. I found it less useful in quick commit-to-staging server process. As some bountiful moments in freenet #svn IRC led me to discover, using post-hook scripts is the way to go.

Check this info box on tigris.subversion.org, leading to this part of ch 5 of the svn book on using hooks to automate and extend commands. There are also some helpful examples of scripts that can be brought to bear on a project.

The code is built thus and left in the hook directory sans .tmpl extension:

REPOS="$1"
REV="$2"

# commit-email.pl "$REPOS" "$REV" commit-watchers@example.org
# log-commit.py --repository "$REPOS" --revision "$REV"

svn update /home/[username]/django/projects/mysite.com/projectdir >> /var/log/vhosts/svn-django-errorlog

Be sure to set your post-commit file to executable

chmod +x post-commit