The new hotness in version control systems are distributed systems like Git and Mercurial. I have used Subversion for many years and have been mostly satisfied with it. I’ve known about Git and Hg but just didn’t have reason to delve into them. But over the past some months I’ve been exploring Git and really like it. It’s time to move Hsoi Enterprises’ source control from svn to git.

Here’s the kink.

About a month ago I obtained new server hardware, which also brought about a major OS change. I brought my svn repository over, but for whatever reason it refuses to work. I’ve pounded endlessly upon apache, but it refuses to allow me access to my repository. Yes, I am giving up. In the end it doesn’t matter if I can get svn serving, because I’m abandoning it. All I really want is to move my existing svn repositories in git, just let me have my data and all my history.

Thankfully my Google searching for ways to beat apache turned up some pages that reminded me about svnadmin dump and load.

It’s been a manual process, but it works something like this (using the PracticeDeck repository as example):

1. Dump the old svn repository

Navigate to the physical svn repository on the server.

$ svnadmin dump PracticeDeck > PracticeDeck.dump

2. Import the svn repository

Since git works locally, I copied the PracticeDeck.dump file to my main dev machine (via AFP file sharing). Fired up the Terminal, cd’d to the place I wanted the git repository, and started work in there.

Yes, you will have to create a local svn repository to import the dump into, which is then used for the git import. This local svn repo is just a temporary artifact.

$ svnadmin create PracticeDeckSVN

$ svnadmin load PracticeDeckSVN < PracticeDeck.dump

3. Create a file to map the authors.

Creating an authors.txt file is useful since git likes to track each commit by the author and their email address, which is slightly different from svn. The file is simple, merely using a “svn-name = git-name” mapping. But I had a problem! In my case my svn repository had no user information! So how to map this?

(no author) = John C. Daub <hsoi@hsoienterprises.com>

The “(no author)” is the magic apparently.

4. Create the git repository

$ mkdir PracticeDeck

$ git init PracticeDeck

5. Import!

$ git svn clone file://$(pwd)/PracticeDeckSVN ./PracticeDeck -A authors.txt --stdlayout

There are numerous ways you can format this command. Some people use the “-no-metadata” option, but I see no harm in doing that and keeping it around. Some Google searching turned up that lacking this created problems down the line, but others just don’t want the clutter. It’s up to you. I opted to keep metadata because there’s no harm (that I’m aware of). I’d rather have it and not need it than need it and not have it.

I’ve also seen some others use different options than –stdlayout, but since my stuff was mostly standard, I just used that to keep it simple.

For the most part, this handled things fine. I’ve seen some folks go in and do some other manual fetching and branching and tagging to migrate their stuff better, but my stuff was simple enough and colored within existing lines for the most part, that the basic clone worked out fine for me.

6. Add other files

I have a habit of keeping some other files around. For example, I’d keep the built binary, the .dSYM file, and other artifacts of release builds. Granted, this is less important to do manually now with Xcode 4′s Archiving, but it’s a holdover habit and even if I don’t do it in the future, certainly I’d like to maintain what I already have.

In my case, my svn repository broke from standard convention and had a layout like this:

/root
  /archives
  /branches
  /tags
  /trunk
  /vendor

In this case, it’s the “archives” directory that mattered. Git doesn’t quite work like svn in this regard, in that there isn’t some separate folder structure you can have (e.g. typically all you work with locally is the “trunk”). I must admit, as soon as I ran into this, I felt like gee, this is one vote for Subversion over Git! But you can deal with it easily enough. For example, I just created an “archives” folder in my normal source code (git) working copy and exported the svn “archives” contents into that folder. Yes, I had to fire up my svn client (svnX), create a file-based repository entry that pointed to my “PracticeDeckSVN” folder, and then I could browse around and do as I needed to. Worked fine. I’m not sure this “archives” folder will make for a good long-term solution… maybe I’ll have another repository somewhere else, or just a simple file structure somewhere because it doesn’t necessarily need to be in git. But for right now, this is fine.

7. Clean up

Delete the “PracticeDeckSVN” folder.

I opted to keep the .dump files in a folder, just in case I need to come back to them later (I can always trash them later)

And then one thing I liked I read about here. When you use “git svn” it keeps a connection to the svn archive as a remote. Well, I don’t want that because svn is going away. So what to do?

$ git config --remove-section svn-remote.svn
$ rm -Rf .git/svn/

And life is good.

If you want, you could go in and delete git branches:

$ git branch -d trunk

In this case, “trunk” will be redundant with “master”, and trunk is an svn-ism that we can get away from.

Of course, any other cleanups and changes you want to do to your new git repository is up to you. Me, I don’t really care. Small team, and I really just want to have all the old history. If the tags and branches and whatever aren’t perfect, that’s alright. It’s good enough for me to get by and move forward in the land of Git.

What’s new in 1.0.1?

• A new attachment type: Ask. It allows you to configure a template but dynamically add an attachment. Gives you the best of both worlds!
• Fixed a problem with voice memo recording on iPhone 4S’s. Fixing this improved recording so there wasn’t a pause of indeterminate length before recording actually started. Audio files are still stored in .caf (Core Audio Format) files, but the audio itself is in IMA4 format, resulting in better compression rates and thus less network data consumption.
• Added some Facebook and Twitter functionality.
• A few other little things and fixes.

Even more people love the notion of the app, want the app, then learn it’s iOS-only… and the smile fades from their face and they put their Android phone back in their pocket. But most follow up by asking me to bring it to Android.

There’s no question that’s my #1 request: bring the app to Android.

Would I like to? Yes. But being a small shop there’s only so much I can do… and it’s a lot of time and trouble to make the port. I had thought about contracting it out to someone else, but then that’s a lot of money I can’t expect to recoup. Not only because I know how much time and effort it took to write the app thus I can make a fair estimate of Android dev costs, but well… Android just doesn’t make much money for developers.

Take this article.

I didn’t realize piracy on Android was so rampant, and so many people proud to do it. It bugs me because I’m sure you work for a living and you wouldn’t like it if someone didn’t pay you for your efforts, or just took whatever you made and didn’t pay for it. So what motivation should I have to make things if someone’s just going to take it and not compensate me? I have a family to feed and only so much time in a day, so I have to spend my time so I can care and provide for my family. Busting my hump for months and getting nothing to show for it doesn’t motivate me all that much, sorry.

Many have told me that the “revenue” model on Android tends to be ad-based apps. But I know ads just do not make much money, except for a few very lucky people. But reading that article, I didn’t realize that there are ad-blockers on Android, and so we’re back to the same thing of people getting something for nothing and the developer loses out.

I’m sorry, but that’s just not motivating. Well it is motivating: motivating to focus my efforts elsewhere.

Do I want to make an Android version? Sure. But I think it’s going to take the larger Android ecosystem to first become more supportive of developers, because right now it’s losing developers. Google, the handset makers, the carriers… they’re going to have to start the change. And yes, the customers/consumers in that realm will have to change too. But it’s a larger change that needs to happen with folks in general.

Everyone hated Metallica when they spoke out against Napster, and while they were wrong in many ways, the fundamental premise what they produce X so they can earn a living, and if people don’t pay them for X, they can’t earn a living. Think about that folks. You really love the product someone provides; doesn’t matter if it’s music or art or software or food or whatever. This person does X because they are good at it, so they work to make money doing what they’re good at so they can feed themselves and their family. If they determine they can make enough money at X to care for themselves, they’ll keep doing X. If they can’t, then they will have to stop doing X and find something else to do, because we all like to eat. So think about that. If you really love X, support the person that makes X so they can keep making X so you can keep enjoying X. Because if you don’t support X, the creator of X will have to find something else to do and X will cease and you will no longer be able to enjoy it.

It’s simple. Support the things you like, that you use, that make your life better in some way. If you support them, they can continue to make your life better.

If you don’t support them, they will vanish and ultimately you lose out.

I also just submitted a bug fix update for kwikkEmail to the AppStore. I’ll post it here when it goes public!

And now to get back to the PracticeDeck. I recently upgraded my source code server and um… have to get a few things fixed there first. *sigh* But, work will recommence soon!

Awesome!

Lots of good apps profiled in that article.

I went with Python because, at the time, it appeared to better serve the needs at hand. I also appreciated Python’s desire to be clean, readable, and maintainable, something Perl seems to take pride is not being. Or rather I should say, I don’t need to live every day in these languages, as I only use them every so often to solve some need. When working in Perl it was very slow because I had to constantly refer to a reference manual in order to understand and remember things. I reckon if I worked in Perl every day, I too would take greater joy in obfuscation. And I must admit… one thing that kept me away from Ruby was reading so much about how it borrowed from Perl. I wanted “anti-Perl” so Ruby didn’t seem like the way to go.

I don’t regret the Python choice at all. It served me very well for my needs, especially when I had to work with embedded scripting support (e.g. Boost.Python).

But like all things in the computing world, change comes. Just a few years ago if you had said we’d all be embracing these little hand-held computing devices to do everything, we would have laughed. But now the iPhone is taking over. And with all this mobile computing, there still needs to be a lot of non-mobile computing to support it. Thus things like “the cloud” are growing in popularity. And what tends to power a lot of that back end?

Ruby.

Or more specifically, Ruby on Rails.

I’m starting to read up on this, starting with the Ruby language itself, and once I feel alright with that, working on Rails. I suspect it’ll come in very handy in the future.

Thing is, Mac OS X 10.7 comes with Ruby 1.8.x, and I want to use the latest 1.9. I found this guide on how to install. Unfortunately it didn’t work because I lack “autoreconf” on my system. But with a little more Googling around, I found the “thoughtbot/laptop script” which seems pretty awesome. It looks to install just about anything and everything you could want and need for this sort of dev work. It’s running right now as I type this up. So far, so good. Oh wait… spoke too soon. Looks like it failed due to some permissions errors. Hrm. I shall investigate.

Yes I am still working on an update to both kwikkEmail and the PracticeDeck, fret not. Just have lots of irons in the fire and have to strike at certain priorities while they’re hot.

I’d also say the iOS App Store needs paid upgrades as well. It’s perhaps a different ecosystem, but it’s still necessary. I can feel the same pain myself, because there’s that whole liking food, clothing, and shelter thing.

There’s not much more to say, since Wil said it all and covered just about every base there is on the topic. Pretty thorough and pretty convincing, at least from a developer’s point of view.

The only question is… will Apple listen?

Xcode 4.4, which is currently a developer preview for Mountain Lion (Mac OS X 10.8) will contain the llvm 4.0 compiler.

There’s a few nifty things in that compiler, such as number literals, collection literals, and object subscripting. Here’s clang documentation about the new features.

Very nice things. Are they totally necessary? No, we’ve gotten along without them for this long. But the syntactical sugar is welcome as it will make it easier to write code. Plus depending just what feature we’re talking about and how it’s implemented, good can come from it (e.g. how the object subscripting is implemented).

I haven’t looked at the developer preview yet, only been able to read about it. I’ll be curious to see how this affects iOS development, since it seems obvious this requires not only compiler support but some changes to the OS as well.

AUSTIN, TX (March 11, 2012) – Hsoi Enterprises LLC is proud to announce kwikkEmail™ as the kwikkest way to send email from your iPhone.

kwikkEmail allows you to get right to the business of composing and sending email.

• Writing it
• Snapping a picture or video
• Selecting a photo or movie from your library
• Recording a voice memo

Download Now!

You use email to manage and organize your life, and you don’t need to wait for mail apps to launch, causing mail to be downloaded and processed, bogging down the network and device keeping you from the important task at hand — composing a new message! kwikkEmail answers this problem and simplifies the task of sending email by minimizing taps, and streamlining workflow.

kwikkEmail fully supports VoiceOver.

“I wrote kwikkEmail out of necessity,” says Chief Architect and Hsoi Enterprises LLC President, John C. Daub. “Too many mail accounts, too slow a network, too much email to manage, and my Mail app and iPhone would constantly bog down and lock up while all this mail was downloaded and processed. Meanwhile I’m sitting, waiting, wasting time, because I cannot get my needed job done: sending an email! Thus, I had to write kwikkEmail to bring some efficiency back to my iPhone’s workflow.”

kwikkEmail is available for free in the Apple App Store.

For more information, visit http://hsoienterprises.com/software/kwikkemail/

About Hsoi Enterprises LLC

After 17 years, Hsoi’s Shop closed and Hsoi Enterprises LLC was opened in 2010. Based in Austin, Texas, Hsoi Enterprises provides technical consulting, and training, bringing together the worlds of mobile computing and personal defense. Hsoi Enterprises strives to provide useful products and services to solve real-world problems. More information can be found at our website: http://www.hsoienterprises.com/

Press Contacts

John Daub

info@hsoienterprises.com

Hsoi, Hsoi Enterprises, kwikkEmail, “The kwikkest way to send email” are trademarks of Hsoi Enterprises LLC. All other product names and trademarks are property of their respective companies.

Long ago I used Projector. Actually before that I didn’t really use anything except making periodic clones and perhaps putting them into StuffIt archives and backing them up to 3.5″ floppy disks. But once I started using Projector and the joys of ‘ckid’ resources, life was never the same.

For a short time there was Visual SourceSafe, but I actually never used Microsoft’s version of it. Metrowerks had made a Mac client for it and I used that, because I worked for Metrowerks at the time. But oh… it was… terrible. I think the only thing I miss from it is Robin Mair‘s PageController GUI widget (revolutionary at the time, and looked damn cool), but otherwise VSS was called “Visual Source Suck” for a reason. Still, it was better than what had come before.

But then we moved on to CVS, which wasn’t horribly bad but was pretty bad. The simple fact you couldn’t rename things was a big problem.

Then then along came Subversion and everyone was happy, because finally we had a CVS that didn’t suck! And that it was, based pretty much around the same concepts and paradigms and CVS, but without much of the suck. And for the most part, that’s what I have used for VCS for the past I don’t know how many years.

Now there’s tons of other stuff out there, then and now, but my developer path never crossed with Perforce or any of the other things out there.

But these days there’s two new hotness: Git and Mercurial (or Hg).

I’ve known about them for a while, but to me it seemed like just another attempt to reinvent the wheel. What did they really bring to the table? Was there really something that was significant enough of an advantage to switch? I never like switching to these things in the beginning because they’re always immature. I mean, when we first switched to svn it lacked some important functionality; it was far enough along to finally start using it on a daily basis but still not 100% there. I don’t need immature tools that then hamper my work in a day.

Not a day goes by when I don’t have some growing interaction with them, especially git due to GitHub. I find a lot of iOS developers using git and GitHub, maybe because Xcode seems to have a built-in preference for it now. I talk with more people using git. I have a little time right now, so I opted to start reading up on git.

I guess the timing is right, because suddenly it makes sense to me. I see where it could be potentially advantageous. I still haven’t actually used it yet, just been reading, but two things happened.

1. On another project, the svn repository is scheduled to be moved from one server machine to another. Work is still being actively performed on this repository. If they did things right, there shouldn’t be any problem nor revisions missed. However, we are anticipating things won’t be done smoothly and revisions risk being lost (better to plan for the worst). The solution? Just don’t commit anything from “now” until we know the server transition completes. This is… not good for numerous reasons.

But it occurred to me that with git, you’d still be able to incrementally work on your code, deal with daily life matters such as realizing you need to roll back, or just ensuring some sort of trail and history of your work. Whatever, all the advantages and reasons for why we use VCS. Then just be sure to do a few extra or special tags or commits regarding the server transition, and then see the state of things after the server move. And if anything was lost, no big deal.

Sure you could still find a way to manage this with svn, that’s more elegant than just “don’t commit”. But still there’s so much extra work and overhead to make it work, at least, compared to a git solution. Or at least, as I perceive a git solution to be.

2. On yet another project, an iOS project, I was in the midst of a lot of work that wasn’t ready to share with anyone. But someone needed a one-off build because we just added their device’s UDID to the provisioning profile. The build machine had problems, I wasn’t in a position to build, but a build had to be made. Thankfully everything just managed to work out, but at that moment when it all came down it would have been disruptive to do the build.

Likely what I would have had to do is hit the VPN, hit the network, checkout a totally new working copy of the project (non-trivial if you have a large project and a slow network; thankfully not the case here but I’ve experienced such projects), then do that as a build. So it’s possible to do, of course. But when I thought about a git solution, it’d be so easy to stash my work away, switch to the master branch, build, then get back to my work.

So yeah.

Now I git it (lame pun).

Now I see some advantage to the tool over existing tools.

I’m going to start playing with it.

Create a dummy repository and just tinker a bit. That “another project” above? It’s hosted in svn and has to stay that way, but I’m going to use “git-svn” to make things go. Thus, it’s all git to me, use git locally for my own work, but then still pipe it back to svn. Hsoi Enterprises code is in svn, and I may start out with it in “git svn” so the code still gets backed up and maintained on another server (gotta slowly break myself of the client-server mode of thinking), but I’m sure if I end up liking git I’ll use it alone tho I may still push to a remote for redundant backups.

The other thing will be seeing how I can integrate back with various GitHub projects. I’ve downloaded numerous Cocoa Touch classes from there, but many had to be modified for some reason or other. Will be curious to see how that all will work out.

It’s always fun to explore new things and find new ways to work better, work smarter, and overcome the little things that get in your way on a daily basis.