20 Jun 2010
Yesterday I took on the task of migrating a remote SVN repository to GIT.
I recently bought a small cloud server from Rackspace with the goal of amalgamating various services I had hosted previously at Webfaction.
The SVN –> GIT migration was simple and painless (thanks to Jon Maddox for the reference instructions). Importantly, all the commit history from Subversion was maintained.
Create a new git user:
adduser git
As the git user
mkdir repos
cd repos
mkdir trunk_tmp
cd trunk_tmp
git-svn init http://x.y.z/svn/trunk –no-metadata
git config svn.authorsfile ~/repos/users.txt
git-svn fetch
The *users.txt *should contain a mapping of svn to git users in the following format:
svnusername = My Full Name
After the git-svn fetch operation has completed (it will download all revisions from subversion and may take a while), do the following:
git clone trunk_tmp trunk
rm –rf trunk_tmp
**
~git/repos/trunk is the new home of your GIT repository.
To access it remotely (over ssh):
git clone ssh://git@/~git/repos/trunk
Simple as that. I’m the only one using the repository so tunnelling it over a single user account is satisfactory. I’d recommend setting up ssh private/public keys to make authentication more seamless.
Resource
31 May 2010
A couple weeks back I set out to upgrade the version of Hibernate Search that one of our applications was using.
The boys at JBoss had recently released Hibernate Search 3.2.0 and it looked pretty sweet. The possibility of performance improvements around indexing was enough to make me upgrade.
Unfortunately, like most software frameworks, Hibernate Search introduced/forced some new dependencies on us. We had previously been using Seam 2.2.0 and Hibernate 3.3.0 (both JPA1), neither of which were compatible with Hibernate Search 3.2.0.
We’re using Maven, so I’ll quickly outline the dependency changes I had to make (*all dependences are available via the [JBoss Nexus Repository*]2):
javax.persistence
persistence-api
<!– bit of a hack to make sure we aren’t transitively pulling in the persistence api (should be referencing hibernate-jpa-2.0-api now) –->
explicitly-fail
javax.persistence:persistence-api is the JPA1 API and is no longer relevant and should never be included as a dependency. The explicitly-fail version will trigger a build failure if it ever manages to sneak in.
org.hibernate.javax.persistence
hibernate-jpa-2.0-api
1.0.0.Final
org.hibernate.javax.persistence:hibernate-jpa-2.0-api is the new JPA2 API published by Hibernate.
All previous hibernate dependencies had to be upgraded to 3.5.2.Final, and Hibernate Search bumped up to** 3.2.0.Final**.
If you’re using Seam, you’ll also need to upgrade it to 2.2.1.CR1. Note that this is not yet a final release but is necessary in order to support JPA2.
Unfortunately, Seam 2.2.1.CR1 lacks a complete Hibernate Search integration. I could no longer able properly inject a FullTextEntityManager (via @In).
Instead I was forced to obtain a FullTextSession programmatically:
private FullTextSession getFullTextSession()
{
Session session = (Session) entityManager.getDelegate();
return Search.getFullTextSession (session.getSessionFactory().getCurrentSession());
}
Seam also enhanced it’s EntityManager so that it now returns a JDK proxy when getDelegate() is called.
That would be fine and dandy, but unfortunately the proxy does not implement org.hibernate.classic.Session, as required by the FullTextSession in Hibernate Search.
Session.getSessionFactory().getCurrentSession() will return an org.hibernate.classic.Session and does allow you to move forward.
A bit annoying and hopefully something that will get corrected in the near future. I’m hoping that either Hibernate Search will be upgraded to not require a classic session, or Seam will provide an EntityManager delegate implementing the classic session interface. Better yet, Seam should just provide a fully supported integration with Hibernate Search 3.2.0.
Honestly, that was about it as far as the upgrade went. We were able to index using either the new MassIndexer API or the old suggested best practice from Hibernate Search 3.1.
It’s interesting to note that on my test system, the MassIndexer API was slower than the previous indexing code. The documentation does cover many different tuning possibilities so it’s entirely possible the situation could be improved.
Also, the MassIndexer API runs in a series of transactions and unless your timeout is set sufficiently high (ie. higher than the default JBoss 5 minutes), you will see transaction timeouts.
I didn’t attempt to work around this and opt’d to stick with existing indexing code that already runs in a separate Seam @Asynchronous method (thus avoiding timeouts).
Somewhat less than ideal, but if you’re keen on running Hibernate Search 3.2.0 w/ Seam in JBoss 4.2.3, it *is possible ***and not too much work.
16 May 2010
A couple weeks back I made a trip down to Seattle in search of an iPad. BestBuy was a complete bust, they get ~10 units in per week and quickly sell out. If you really want one, you’re going to have to visit an actual Apple store.
That same weekend, I also picked up a Netbook for the girlfriend. It was a much easier buying experience, they’re everywhere. We ended up picking up an Acer from Costco for $499.
First things first, the iPad is not a laptop replacement IMO. It’s certainly sexy and crowd pleasing, but if you’re looking for a communication device in the sense of sending emails, video conferencing, etc., you’re better off with a Netbook (MacBook Air included). The virtual keyboard is passable, but not terribly suited to significant correspondence. Plan on grabbing the Apple bluetooth keyboard if you’re looking to publish content via the iPad. Lastly, if you’re the attention seeking type sporting a permanently popped collar, the iPad is a surefire crowd attractor.
On the flip-side, if you’re looking for a new content consumption device (twitter, google reader, books, etc.) it really is your ticket to ride. I’ve been running a little test over the past couple weeks where I’ve restricted Twitter and RSS usage to the iPad. It’s completely anecdotal, but it seems much easier to keep up to date on the iPad versus say using Tweetie or Google Reader on the MBP.
The Flash argument is a non-starter for me, 99% of the sites I access on a regular basis are fine. Once FailBlog converts over to HTML5, I’ll be set.
Furthermore, just being able to sit on the couch or lay in bed and not end up with a 3rd degree burn, makes the iPad worth the price of admission.
As I type this, the girlfriend is happily skyping with friends and tagging faces in Picasa. Being able to do both at the same time is an obviously technological and patentable marvel!