LG KC910 woes

As I've already said in earlier postings I relatively recently got myself a LG KC910 Renoir phone. The phone has been the cause of a lot of woes and problems so far and I'm afraid I must say I regret not getting a proper Android or iphone from the beginning. As it is, I'm stuck with this phone for another year+ until the subscription runs out - or get some other phone on my own tab.

The one really great part that I love about the KC910 so far is the absolutely wonderful camera, it has a 8MP camera that takes rather splendid snaps for a cellphone camera. Also, the video recording function, and video/music playback is rather nice.

For the really really bad part, well, look at the rest. Three of the main reasons I got this phone was for the ability to get some websurfing done "on the go", and to get a good calendar that could be synced vs my work and private calendars, and finally I wanted to use the phone straight off for connecting to the internet instead of some dongle. Both these functions are completely botched in the KC910 as the, the webbrowser lacks a lot of functionality practically making most of the internet unusable on the phone, and the browser is also horribly slow, taking tens of seconds to "calculate/draw" complex webpages after its actually loaded. This problem should be easily solvable by downloading and installing another browser such as Opera you say, sadly, the install process hangs halfway through on the Renoir, and I have so far to find another browser that actually installs at all, which kind of brings a fourth point up (applications/third party market).

Second problem was the calendar, which is unfortunately totally borked. For basic calendar tasks it works fairly well, but very soon you will realize it doesn't work very well. It lacks good support for reoccuring activities, the sync applications has a bad habit of screwing up timezones and actually moving activities/entries around based on timezones and at occasions it deleted entries entirely, and worst of all, LG has chosen to go all the way with their PC Suite set of applications, which essentially bars you from using anything but officially supported Microsoft Windows XP/Vista and Outlook. This goes for pretty much all functionality in the phone. Getting it to work with thunderbird, well, good luck. This is one of the reasons I had to work very hard getting Funambol setup at home to sync the phone and thunderbird with (I can not use a third party server as some calendar entries may in worst case contain sensitive data). The functionality of this setup worked out to be "semi-decent" to crap at best, and in the end I winded up reverting to just using my computer calendars.

My third problem has been internet connections. The only supported way of connecting to the internet is (again) via their PC Suite crapware. All other phone manufacturers support Bluetooth DUN or serial port connections without a problem, but not LG. It halfway supports DUN connections, I get a connection the first time that doesnt work, then get disconnected, and after that it takes 2+ days until I can connect again, and get disconnected again, exactly the same thing happened in Linux, Vista, XP, with/without PC Suite, over USB/Bluetooth, in accordance with 3's and LG's support etc. In the end, after 3-4 weeks of messing with this, I winded up getting a Huawei E180 HSPA USB stick, 30 seconds to unpack, plug in and click two buttons in Ubuntu and I was connected to the Internet.

My final annoyance is the lack of a third party aftermarket of some kind, I'm talking anything like the Iphone/Android app-store. A smart phone without a serious aftermarket support is pretty much as dumb as any old "dumb phone" ever was. LG has some eclipse based SDK's available for download, but they only work for Windows, which has stopped me from actually trying them out at all so far, as I quit using windows completely half a year back. Anyways, the big problem is that there is no coordinated effort to make a decent app-store or app-store-a-like place to go for your applications for this phone. As always, the phone producers completely fails at understanding this part, in this day and age, you need to create officially endorsed systems of managing, getting and paying for applications. Whom the problem should fall upon is a hard question, but just dumping the problem on someone elses porch is not sufficient in this day and age, especially if you want to make phones that tries to emulate the success of "the big one", you need to at least try and understand what made it big. It wasn't a good camera or a nice looking (but slow) gui. It's the ability to be adapted to my requirements, and to perform my required tasks. You can not predict it all (my needs are not your needs), hence adapt to standards (make shit plug and play with others), and make every effort you can to create a third party aftermarket that works (signed downloads, payments, etc etc).

As a verdict, if you're looking for a smartphone/iphone/android, dont get an LG.

"New" subversion structure using svn:externals

Me and the boss deviced a new structure for the project during the last few weeks, and it's been slowly refining in our heads until yesterday when we finally implemented it. I think we made a rather refined and complex structure, but once we got it into place physically and once we get the general idea into the developers heads (including me), I think it will prove very powerful.

That being said, I don't think this is a new structure, I just think people are very quiet about how they use subversion, and it's a problem. Newcomers do the same old errors over and over again. So, let's get on to try and explain it all.

Most projects uses a single BTT root, where BTT stands for Branches, Tags and Trunk. Ie, they start a project, and then straight in the root put the BTT, and then inside that, they create the project structure. For example:

• project-root/
• Branches
• Tags
• Trunk
• admin
• src
• out
• test

This is a good basic structure for very small projects, containing perhaps 10'ish files, or where the actual implementation is perfectly homogenous and has no need for separated versioning. Every time we want to make a release, we cheap copy the content to Tags as a new tag (called perhaps /Tags/Milestone1-RC1). We now have a release that we can provide to people.

The problem comes if it isn't so homogenous. For example, let's say you are developing a calculator. It has two objects, a numpad and a display. What if you want to make a new version just of the display? You need to make a completely new version, including for the numpad.
Or how about wanting to branch just a small part of the project? Ie, I want to use a branch for the numpad, and then use the trunk for the display. You'd then have to make a cheap copy for the entire tree. Admittedly, it isn't costing too much.

Our "new" structure deals with this on a different level. Basically, the idea is to have multiple BTT roots, and then use svn:externals to connect the correct tags to create
1) a complete releasable project and
2) a complete workarea project.

For the calculator example, you get the following structure:

• calculator/
• Calculator_Modules/
• Display/
• Branches/
• Tags/
• Trunk/
• Numpad/
• Branches/
• Tags/
• Trunk/
• Calculator/
• Branches/
• Tags/
• Trunk/

As you can see, it looks much more complex, and it is, but the possibilities are infinitely much better.

The Calculator/Trunk/ directory contains a svn:externals property linking in the Calculator_Modules/Display/Trunk as Display and Calculator_Modules/Numpad/Trunk as Numpad. This works by linking external resources into the current directory structure, so basically I would get the trunks into my Calculator trunk, but properly renamed, without them actually being there in the repository. This also works on "real externals" by the way, such as linking in a specific version of a library from some repository on the Internet.

To create a Calculator/Tags/MS1 we could either just set a -rXX to the correct subversion revision, or we would create svn:externals to the correct Display and Numpad Tags, not their trunk. This way, we can say that "Calculator 1.0 contains Display 2.0 and Numpad 2.1", not "Calculator 1.0 contains Display revision 439 and Numpad revision 587", or even worse "Calculator 1.0 is revision 587" which completely lacks granularity.

I'm not completely sure it's perfect, and others have probably already tested it, but I think it will be pretty sweet :-).

Dangling locks in the Subversion tree

I recently ran into another rather peculiar and interesting case with subversion. As I've already explained, I don't have actual physical access to the subversion servers we are perusing for our project. We use TortoiseSVN for access to the repository on our local systems.

My boss was working with some excel and word files checked into the repository. He had template.xls locked as he was working in it, he decided to rename it to a template, so template.xlt it is (and checked in). After doing some more work, he decided this was a bad idea, so he changes it back to template.xls, and tries to check it back in again... no luck, it wont work.

15-20 minutes worth of investigation later, we found the problem. TortoiseSVN had been configured to always check "Keep Locks" on commit, hence the client kept the lock when he commited the template.xls deletion. To fix this problem, run svnadmin lslock and then svnadmin rmlock the file in question. Please note that this requires actual access to the physical subversion repository. Http or svnserve will not do in other words.

A step by step on how to cause the Dangling lock problem -- All of the actions are done via TortoiseSVN interface:

1. Create a repository.
2. Check out the repository.
3. Add a file to the repository, set the svn:needs-lock property.
4. Commit the file.
5. Lock the file.
6. Change name of the file, and check the "Keep locks" checkbutton.
7. Commit the changes.
8. Change the filename back to the original filename.
9. Commit the change. This step will fail.

This is a rather funny problem imho :-). We finally managed to get it fixed after contacting the IT department and sending them the command. 10 minutes to cause the problem, 20 minutes to analyze it, 20 hours to wait for the fix. Sometimes there should be less depth in organizations.