Mind Your P's and Q's

So I realized today that the last couple of zip archives I posted were probably *not* updated from the new svn repository on the riaforge site but rather older copies from the svn repository I had on my local machine. They were properly zipped (which was the last issue, unrelated to svn) and therefore would install properly into the framework via the plugin manager... Thing is, exporting and zipping archives and uploading them is tedious and frustrating -- or at least I find it to be... and so I have these batch files on my local machine that I use to pack them up and at one time the bat would even upload the archive to the public server when I maintained a dedicated server for the framework.

So when I was done committing my changes to svn all I had to do was double-click on my bat and walk away.

Instead of

1. delete folder
2. create folder
3. right-click -> svn export
4. enter repo url (I maintain several)
5. wait for export to complete
6. right click -> send to -> compressed folder
7. right click -> ws ftp upload
8. select server -> select subdirectory -> upload

So I had these bats which worked fairly well for me for a while, and may or may not have been a product of my never having learned ANT.

And when I set up the projects on RIAForge I apparently forgot to update the distro.bat (which is called by the bats for individual projects so they're not all copy/pasted) to use the new svn repositories on the RIAForge server. So when I realized this today I started updating the projects again and getting ready to upload new zip archives (current archives) and immediately started getting this error from svn:

Honest to god, I was using Google to solve this and it took me over an hour of pulling my hair out (and Google was no help)...

I'd like to take this opportunity to reiterate that CASE SENSITIVITY IS A BOIL ON THE ASS OF SOFTWARE!

We are well past the point at which there is any significant performance gain from the choice for a language to be case sensitive, which was the original impetus. Back in the day, when "no one would ever need more than 640k of memory" things were different, and a person might actually notice in some cases when software took the time to convert all its data to upper or lower case before performing comparisons if there was a lot of data being moved around... But on today's machines, no one will ever notice.

We keep case sensitivity around today because programmers forgot the original impetus and are now married to this disgusting notion that case sensitivity is better because it's "precise". There is not now, nor has there ever been a "value added" to a piece of software as a result of its being case sensitive. Software that supports *nix should for everyone's health and sanity be case insensitive and force their users to save files in lower case.

Harsh? This isn't the first time I've seen it happen specifically with svn. The last time it took 3+ hours of hair pulling from another friend of mine before he realized that their svn repository was royally f*ed up because some file had been given a name that varied only by case from a file next to it on a *nix machine (i.e. application.cfm vs. Application.cfm) on a project that had developers using both *nix and windows platforms for development. Again in his case as in mine, NO VALUE WAS ADDED by the support of case sensitivity. It took him 3+ hours to isolate that issue because the errors caused by case issues almost never indicate that case might be an issue, and it's always the furthest thing from your mind when you start troubleshooting. Which immediately sends you off into one of these 3 hour hair-pulling frenzies. Nor does any appeal to Google or any user-groups or mailing lists help either, because it's also the furthest thing from their minds.

And just to underscore my point... There's always that case in development when you're having to convert data from one language that's not case sensitive to a language that is... like for example, SerializeJSON! Great function! Awesomely helpful! Totally easy to F*** UP unintentionally! I'm not complaining about the folks at Adobe (although honestly I would have wrapped an lcase() around all the keys being serialized for everyone's sanity). Thing is, what you get out of a SerializeJSON function will vary based on something that you're usually not thinking about... for example:

struct = XMLParse("<x foo='bar' />").x.xmlAttributes;

foo is lower case

struct = { foo = "bar" };

foo is UPPER case (I think)

struct = structNew(); struct["foo"] = "bar";

foo is lower case

struct = structNew(); struct.foo = "bar";

foo is UPPER case

So ... if someone else is editing a totally separate section of your application and decides to change for example:

<cfset foo.a = "" />
<cfset foo.b = "" />
<cfset foo.c = "" />
<cfset foo.n = "" />... 

to

<cfloop index="c" from="#asc('a')#" to="#asc('z')#">
  <cfset foo[char(c)] = "" />
</cfloop>

Suddenly your javascript receiving the SerializeJSON data blows up in your face because somebody decided to replace 26 lines of code with 3 further up for legibility. You come back in and fix it by putting in [ucase(char(c))] (so your javascript is getting capitalized letters again). So the next guy comes along and being a ColdFusion guy thinks "gee, aren't those the same thing?" and removes the ucase() because it's not needed, not realizing that it's necessary for the SerializeJSON call in another template.

In my case? My subversion repository is named MembersOnTap. Again... it's always the furthest thing from your mind... When I set up the riaforge projects, it didn't occur to me that having the url "http://onTap.riaforge.org" might mean that the svn repository would be case-sensitive, and again the same for the sub-projects, which are now

• http://svn.riaforge.org/onTap
• http://svn.riaforge.org/plugtap
• http://svn.riaforge.org/MembersOnTap
• http://svn.riaforge.org/tapmce

So... once again... new zip archives just published for the individual projects.

Enjoy!

And apparently if you use SVN, mind your p's and q's.