Inconsistent line ending style upon Subversion Import / Commit 0

For posterity and my future sanity (and hopefully this helps the rest of us SVN-crazy developers).

When doing IMPORT or COMMIT operations using Subversion, we can receive a message like “Inconsistent line ending style”.

Particularly when IMPORTING, this can be a frustrating occurrence, with a host of hints provided online, but I couldn’t find anything but “brute force” approaches of converting EOL symbols by touching each file.

I use [auto-props] in my svn config file, and this is both part of the problem and the ultimate solution.

The latest occurrence happened when IMPORTING several XML files into a Repository. The confusing part is many of the XML files reported success, and then SVN hit an XML file with a different EOL style than all the others.

My auto-props entry used to be: [plain] *.xml = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Date Revision[/plain]

Here’s my solution (svn config file): [plain] [auto-props] *.xml = svn:mime-type=text/xml;svn:eol-style=CRLF;svn:keywords=Date Revision [/plain]

[plain] [miscellany] enable-auto-props = yes [/plain]

Hopefully this helps you out as well.

kick it on DotNetKicks.com

Continuous Integration Gotcha: NAnt empty elements 0

For those of us using the TeamCity continuous integration tool, I ran across a gotcha this morning that I will forget very soon.

The problem

When running NAnt script on my local machine “in developer mode”, everything runs fine. However, once it goes to TeamCity, it puts up a general error:

Could not include build file ‘X:\teamcity-BuildAgent\work\684ab6ff82f1a29a\build\foo.core.build’. Object reference not set to an instance of an object.

In the end, my offending entry was:

<fileset id="cube.load.files">
  
</fileset>

Here’s my NAnt file pattern. I use a set of local.properties.xml for a development machine. I also create a buildserver.properties.xml for the TeamCity run. Then I create a “wrapper” NAnt file that includes both the CORE build script as well as the *.properties.xml file for the given environment.

This has worked very smoothly in the past so this morning it was rather frustrating to receive the error. The inspiration for this methodology was inspired by Jean-Paul’s excellent NAnt series. I highly encourage you to check it out.

Back to the problem… When running under TeamCity, I get a failure to include a build file, but everything works when running on a development machine.

The Solution

Remove EMPTY elements from the XML-formatted NAnt file (or close them using shorthand). For some reason, it looks as if TeamCity’s NAnt runner is parsing those files before sending them over to NAnt (guessing here).

And once I cleaned up this empty element, it worked! Interesting how this yet another reason why XML is the bane of developers.

[xml] <fileset id="cube.load.files" /> [/xml]

Gotcha of inline Document Ready function for JQuery 5

I’ve had some reasons to use JQuery this week, and you should believe whatever good rumors and hype you’ve heard about this library. It’s amazing.

There are many benefits to a Javascript framework, particularly JQuery. Take this example that I put inside my <head\> element: [xml] <script type="text/javascript"> $(document).ready(function(){ $(‘#deliciouslogin’).submit(function(){ alert("This to authenticate with Delicious and start retrieving Bookmarks into Google Gears database"); }) }); </script> [/xml]

This is the “Document Ready” function. This solves the problem of running your Javascript code before your page is done rendering on the browser. Also note how easy it is to hookup an “onsubmit” event handler. You use CSS-selectors to identify what HTML element(s) to apply to, and JQuery does the rest, figuring out the best way to accomplish that regardless of your browser. Great fun.

My elation quickly disappeared when I fired this sample up in FireFox 3, nothing happened when my <form>’s submit button was triggered. Frustrated, I quickly tried it in Safari (Mac), it worked fine. I switched to the PC and grumpy IE6, and again, no luck. So what’s going on?

It turns out that the inline JavaScript will be ignored if you close the element just prior in your <head\> section with the shorthand closetag />.

This doesn’t work: [xml] <script type="text/javascript" src="lib/jquery/jquery.js" /> <script type="text/javascript"> $(document).ready(function(){ // blah }) }); </script> [/xml]

This does work: [xml] <script type="text/javascript" src="lib/jquery/jquery.js"></script> <script type="text/javascript"> $(document).ready(function(){ // blah }) }); </script> [/xml]

Hopefully I will remember this in the future, as this is now the second time in two days I’ve wasted an hour or more wondering why my Javascript wasn’t activated.