Tuesday, March 31, 2009

Upgrading an SVN Vendor Branch

The dojo toolkit just announced the final 1.3.0 release of their toolkit today, which is great news for us, as we've been waiting on some 1.3.0-specific functionalities to deploy in our site.

In our SVN repository, we've got a "vendor" branch set up according to the instructions laid out in the Vendor Branches Section of the Branching and Merging Chapter of the SVN Book. In it, of course, we have a /dojo directory.

So the deal now was to follow the instructions from the SVN Book and upgrade to 1.3.0 release.

Much to my dismay, I got hung up on the very first stage:

To perform this upgrade, we check out a copy of our vendor branch and replace the code in the current directory with the new libcomplex 1.1 source code. We quite literally copy new files on top of existing files, perhaps exploding the libcomplex 1.1 release tarball atop our existing files and directories. The goal here is to make our current directory contain only the libcomplex 1.1 code and to ensure that all that code is under version control. Oh, and we want to do this with as little version control history disturbance as possible.

What I did was

  • download the latest release
  • unzip it into a local checkout of /vendor/dojo as /vendor/dojo/1.3.0-release
  • mv /vendor/dojo/1.3.0-release /vendor/dojo/current
But then when I did 'svn stat', instead of showing me a list of all the changed and new files, it just said:

    ~current

and svn stat help tells us:

    '~' versioned item obstructed by some item of a different kind

...which makes sense, but unfortunately didn't really help. It said to "copy new files on top of existing files", and that's what I was doing.

Obviously, the problem is that by just copying the directory over, all the special .svn information was getting blown away. What I needed was a way to copy all the *files* into that /current directory... without destroying the existing directory structure.

Well, after a lot of searching, I finally found the answer in a video on the gotdrupal.com website. In a nutshell, it is a very detailed, patient walk through of the "Vendor Branches" section from the SVN book (see above).

Turns out, the trick (or at least one of them) to getting those files to overwrite without confusing SVN is to download a tarball of the release and then un-tar it right into the /current directory, but using a special --strip-components=1 flag.

If you are curious about the "right" way to set up a vendor branch, I highly recommend reading the Vendor Branches Section of the SVN Book and then watching this great video.


Thursday, March 26, 2009

Off to a Bad Start with GWT


So I've just spent the last few hours battling with an obscure Eclipse/GWT bug. 

The official bug report for this beast I find very appropriately titled: GWT project creation indefinetly creates folder recursively.

If you're new to GWT (like me) and you find your machine spinning in circles as you innocently follow the instructions listed in the Getting Started - Quick Start section of the otherwise generally helpful docs section of the Main GWT page, CLICK CANCEL IMMEDIATELY!!!

Confused code is creating a rabbit hole as deep as your wildest imagination on your computer.

Once the damage has been done, the tricky part is cleaning up the mess. The crucial problem here is that Windows can not deal with file names longer than 256 characters. "So what?!" you say, "Can't you just delete the directory and be done with it?"

Shouldn't it be so easy. No, Windows is so freaked out it can't even deal with deleting the thing.

Most of the suggestions I could find on the web as to how to delete these undeletable files suggesting a wierd trick where you map a network drive to one of the folders deep in the hierarchy... effectively chopping off all the preceding path and replacing it with a single drive letter. One friendly helper on the ticket/thread for this bug notes, helpfully, that "You may have to do this more than once."

Exactly. More than once indeed! This is recursion we are talking about here. Computers are fast... and yours truly multitasked the Eclipse window out of sight and mind for a good five minutes before checking back and kiling it. As you can imagine, this netted me a very, very, very, very deep mess of recursive directories.

So I figured, the best way to solve this issue was to take matters into my own hands. So I wrote a little batch script to fight fire with fire: recursively move and delete until all gone. 


:LoopStart
IF EXIST MyProject/MyProject GOTO :KillAChunk
GOTO End

:KillAChunk
move MyProject/MyProject foo
rmdir /s /q MyProject
move foo MyProject
GOTO LoopStart

:End
IF EXIST MyProject rmdir /s /q MyProject

...create a new notepad file called "killer.bat" or something of the sort, paste that text into it, and save it in the directory where you find the first "MyProject" directory. Now just double-click killer.bat or run it from the cmd prompt and voila! All cleaned up.

I hope that helps someone/anyone out there who ran into this problem. Very annoying! It would be kind of the good people at Google to at least add a warning in their documentation to prevent others from falling into this trap.

Tuesday, March 17, 2009

Invisible Dojo 1.3 Calendar in Chrome, Safari

So we've been experimenting a bit recently with the Dojo Framework, a Web 2.0 JavaScript toolkit.

Specifically, we were interested in the Calendar widget, which is part of the Dijit package.

After a bit of poking and prodding, we were able to get the widget working. Great!


Much to our dismay, however, in the Chrome and Safari browsers, we were getting script errors and our slick new calendar was not showing up at all.

My first crack at fixing this issue (and in fact my motivation to write this blog entry) was to run some Google searches to see if anyone else was having the same problem. I am the first to admit that I am no Google wizard, but my best shots at combining "dojo", "dojo 1.3", "calendar", "chrome", "safari", "bug", "invisible".... all turned up unhelpful links.

Thus, it was time to step into the code. This was my first foray into debugging in Chrome, and with a lot of banging at the console command line and a little help from a post by Eric Pascarello, I was able to trace the bug down to a null return from the dojo.query() function.

Now a second round of Google searches incorporating "dojo.query" instead of "calendar", and bang! The first result was a link to Ticket 8775 in the Dojo TRAC, whose title is "REGRESSION: Camel Cased classname queries fail on Safary [sic] 3.2.2 and Chrome".

Well what do you know. It turns out we were just a little behind the times. We were working off of the 1.3 beta 1 release. The bug had since been tracked down and fixed... and all we had to do to get our calendar to show up in Chrome and Safari was to upgrade to 1.3 RC1 (The most recent release at the time of this posting).

So voila! Hopefully there's enough relevant keywords in here that all the other folks out there running on one of the 1.3 betas might find this and realize it's time to upgrade!

Cheers to the dojo community for putting together such a great product, and for really being on the ball with finding and fixing bugs like this.


Welcome



Welcome to the Travel Tripper Tech Blog!

In this space we will be posting thoughts, discoveries, insights, rants, etc. regarding the different tools and technologies that we are using to build cutting edge web software.

A little background about Travel Tripper, we are a small company of about fifteen employees, based in New York but scattered around the world. We build software to help hotels improve their web distribution/sales. You can find out more about us at website at www.traveltripper.com.