Git advantages in the corporate environment

I've come across a couple of  blogs and message board posts (some of them admittedly dated) lately which insist git is not usable in a corporate environment because:

• git is not centralized.

Corporate environments MUST HAVE a centralized solution for backup purposes

• git does not have canonical revision numbers.

Corporate environments must have canonical version numbers.

 

The Backup Issue

The first point is of course, invalid.  Git can be used in a centralized manner, making all the backup monkeys happy.  Used in this manner, it's not different from subversion in that the repository exists on a server and it can be backed up.

However, that ignores a far bigger point. What if your IT department isn't quite as awesome as they think they are?  What if you were told about the crack sysadmin team, only to learn the system admin is low-rate overseas hourly worker?  What if he didn't quite get that backup job done before the bus came?  What if he hasn't checked if the script he wrote 4 months ago is still working?

One night your server stops responding, and after opening a case with IT, you learn to your horror that they're unable to restore the backup.

Not to worry, right?  Every developer on the team has a copy of your subversion repository, right?  Wrong.  They have a single checkout of repository.  One version.  Need to revert to a previous version? Can't do it.  Need to look at the changes involved in a particular bug fix?  Not happening.  Need to review the commit messages for a particular commit? Sorry, the entire log is gone.

This differs markedly from the git world.  In the git world, should your centralized repository be lost, every single developer has a copy of the entire repository.  It is possible that if a developer hasn't updated between the time another developer pushed some commits and the central repository was lost, he might be a couple commits behind.  This is true in the subversion world too.  If developers hadn't updated before the repository was lost, only the last person who checked in will have the last few commits.

It can't be stressed enough how much better your situation is with git.  Think about it.  With subversion, you'd figure out who had the up-to-date copy of the repository.  Then what?  You can't find out what revision your teammate had and send him a patch to bring his copy of the project up to date, since subversion can't generate a diff without access to the lost central repository.  I suppose the most up-to-date developer could put his copy on a file share somewhere and developers could manually diff the files and apply any changes.  Yeah, that's it, what fun.

The other choice of course is just to take the most up-to-date developer's project and use it to create a new subversion repository.  That will work and the team will be able to check out an up-to-date copy of the project.  An up-to-date copy with no history, no previous versions, nothing. Certainly not what one would consider "enterprise-level source code management."

Oh, but it also gets better.  What if your team's discipline is really lacking, and nobody has a version checked out that actually works?  You're hosed - you can't revert to a known working version - you have no central repository anymore.

Now let's look at the git situation.  Like with subversion, the team is likely to figure out who has the most recent copy of the repository.  With one command he can generate patch files that his colleagues can run to bring their repositories up-to-date before any kind of centralized server is restored.  Depending on the size of the team, team members could be completely up-to-date, sharing changes again and productive again literally within a few minutes.

Oh and those patch files?  Not only do they update the code to the correct state, but they also include the log messages, commit hash, etc.  So when the patches are applied, the resulting repository looks EXACTLY like the repository from which it came.

The Revision Number Issue

I don't know who came up with this gem, but talk about a ridiculous argument. Someone tell me what a canonical version number is?  Is it sequential?  Is it unique? Is it alphanumeric?  Is it octal?

Although subversion has simple version numbers, they're not particuarly useful.  Sure, I can tell my team member - "Hey, create that branch off revision 2142 of trunk," but that doesn't do him any good other than pointing to a version.

And while you would think you could figure out relationships between revisions using the revision number, it's actually difficult to do so, since revision numbers are global and increment when other developers check in, or even when some checks in on another branch.  So, think that revision 10 on trunk is the result of 5 commits on trunk since you checked in revision 5?  Could be, but it also could be that someone checked in 4 revisions to a branch, so that revision 10 actually follows revision 5 in trunk.  Not much value there.

Now, git has those super-complicated hex-looking numbers.  I mean, really.  We as developers are supposed to be able to deal with these hex strings?  How ridiculous is that?First of all, let's get the easy part out of the way.  Those big hex numbers are not difficult to deal with because we can shorten them dramatically.

In small repositories, four characters is sufficient.  In large repositories, 4, 5, or 6 characters is certainly going to be sufficient.  No more difficult than typing version "21042."  And of course we can use all sorts of symbolic names and expressions such as HEAD, HEAD^ (the parent of HEAD), time-based specifiers and others.

More importantly however, the commit is a hash of the branch at that particular time.  What this means is that you can GUARANTEE that code with the same hash is exactly the same.

Here's how cool this is:

Let's say for a minute that the repository that went down was a public project that my company exposes to the outside world and allows others to clone.  And now let's say that somehow, some way, I lost the last 5 commits out of that repository.  I have a copy of the log, so I know what the commits were, but I already checked with everyone in my company and nobody has a copy of those commits.Oh man, I'm in big trouble.  I don't have a trustworthy source.

Can I really just reach out to the some random 12-year-old on the Internet that has a copy of the repository and ask for a patch containing those commits?  Maybe I should find someone that works for another large company.  Surely that's a good way to make sure they're trustworthy.  Or maybe I can get my company to pay for a background check on someone.

The fact of the matter is, if you have the hash, you need not worry.  The code could come from the most notorious hacker group on the planet and as long as the hashes match, I know they did not change one single bit in my code.

Conclusion

Wow.  That's a lot more than I intended to write.  But hopefully you can see now why such arguments are not only ridiculous, but just plain wrong.

For the Mercurial fans out there, readers should note that I'm willing to bet Mercurial has the same advantages as git in these areas.  Both are excellent DVCS systems and I wouldn't hesitate to use either.

Finally, I do recognize that there are situations for which a DVCS may not be appropriate.  If you have terabytes of data in your repository, git or hg is probably not for you without a lot of repository re-organization.  In those cases, by all means stick with your centralized VCS.  Just realize that because you have something preventing you from using a DVCS doesn't mean the DVCS advantages don't still exist.

SQLite2 source and errors

Every once in a while, I come across a SQLITE2 database that needs to be converted to SQLITE3 format.

Doing so is easy. You just dump out of SQLITE2, and import into SQLITE3, such as:

sqlite2 mysqlite2db.db .dump > sqlite2_mysqlite2db.dump

sqlite3 mysqlite3db.db < sqlite2_mysqlite2db.dump



One problem is though, SQLITE2 is often not available anymore through any of the standard Unix package management systems. So if you have a newer machine with an app that's utilizing a SQLITE2 database and you want to upgrade that app to a newer version that uses SQLITE3, it's tough to get SQLITE2 installed so you can do the conversion.

What I did is download the SQLITE2 source code from:

http://www.sqlite.org/sqlite-source-2_8_17.zip


Then I compiled. (Remove the tclsqlite.c file. It's not needed)

This is on Debian Linux, BTW.

gcc -o sqlite2 *.c


That worked and got me a sqlite2 executable. However, when I tried to use it on my SQLITE2 database, I got:

sqlite2: btree.c:702: sqliteBtreeOpen: Assertion `sizeof(ptr)==sizeof(char*)' failed.

Hmm...what the heck?

I didn't carefully read the error and instead quickly went to googling. However, I didn't find much in the way of help. However, it quickly struck me that this was a 64-bit problem. Aha! I had forgotten to compile the program with the 32-bit flag. No problem.

(On OSX the flag would be -arch i386)

gcc -m32 -o sqlite2 *.c


But that gave me:

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory


After a little googling on that, I discovered I needed to install the lib6c-dev-i386 package, since I was running on an AMD 64-bit system. I installed the package, recompiled and everything is working fine.

Installing Ruby 1.8.7p352 under rvm

I was recently trying to install Ruby under RVM on OS X, 10.6.8, running in 32-bit mode.

For Ruby 1.9.2 p290, it was no problem. rvm installed it without issue (using x86_64).

However, Ruby 1.8.7 p352 would fail constantly, with:

making ruby
/usr/bin/gcc-4.2 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp  -fno-common -pipe -fno-common    -DRUBY_EXPORT  -L. -arch i386 -arch x86_64 -bind_at_load   main.o  -lruby -ldl -lobjc   -o ruby
ld: warning: ignoring file ./libruby.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
  "_ruby_init_stack", referenced from:
      _main in main.o
  "_ruby_init", referenced from:
      _main in main.o
  "_ruby_options", referenced from:
      _main in main.o
  "_ruby_run", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/rp/rprVpkCiGbKvS3sirOXX9k+++TI/-Tmp-//ccoGzQBh.out (No such file or directory)
make[1]: *** [ruby] Error 1
make: *** [all] Error 2

You can see above that files are getting correctly compiled with both the -i386 and -x86_64 -arch flags. That was confusing. I verified that the Makefile included the arch flags on both the CFLAGS and LDFLAGS variable.

I traced the problem to the following line of output:

cc -dynamiclib -undefined suppress -flat_namespace -install_name
 /Users/wwilliam/.rvm/rubies/ruby-1.8.7-p352/lib/libruby.dylib 
-current_version 1.8.7 -compatibility_version 1.8   array.o bignum.o 
class.o compar.o dir.o dln.o enum.o enumerator.o error.o eval.o file.o 
gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o 
parse.o process.o prec.o random.o range.o re.o regex.o ruby.o signal.o 
sprintf.o st.o string.o struct.o time.o util.o variable.o version.o  
dmyext.o  -o libruby.1.8.7.dylib

As you can see, the dynamic library is being linked here without any architecture flags. What needed to be set is the LDSHARED variable.

My first attempt was to modify the Makefile by hand, adding the -arch flags to LDSHARED. That worked - somewhat. I was able to run make and get everything compiled. However, that didn't solve the problem completely, because whenever I tried to install via rvm again, my changes were overwritten since rvm ran configure again.

Naturally, for my next attempt, I did a "export LDSHARED="-arch i386 -arch x86_64" in the terminal in which I was running rvm install. That also did not work. I checked and config.log DID show my additions to LDSHARED. Hmmm...WTH?

It turns out that the configure.in defines LDSHARED explicity for each machine type and does not use the value that configure picks up.

For darwin, it was:

        darwin*)        : ${LDSHARED='cc -dynamic -bundle -undefined suppress -flat_namespace'}

So the fix in this case, was to change it to:

        darwin*)        : ${LDSHARED='cc -arch i386 -arch x86_64 -dynamic -bundle -undefined suppress -flat_namespace'}

I did submit bug #5295 against Ruby 1.8 for this issue. Whether it will get fixed or not, I don't know.

Update on VATSIM work

I realize I haven't posted on this blog in many months, but I thought I'd do a short update just to talk about the things I've been working on.

Most of my work recently has gone into the VATSIM FSD. None of the changes have been earth-shattering, but they have involved things like updating the FSD to work with sqlite3, changing its build system to Cmake and improving its method of locating its configuration files. None of those changes will be noticed by VATSIM users, but they make life easier for those of us who work on the code and support the servers.

For those of you waiting with bated breath on the upper-layer wind improvements I've been working on, the bad news is it's still not finished. The good news is I've started working on it again. I'm currently in the process of changing the backend database from MySQL to Postgres. Once that's complete, I'll be able to go back to finishing up the wind management code.

Converting Bazaar Repositories to Git

I have enjoyed using Bazaar. Its flexibility is tremendous. I've always used whatever SCM system I was using from the command-line and avoided turning on integration in the IDE since it seemed to cause more problems for very little benefit.

However, after watching some of the Xcode 4.0 WWDC videos, I've realized the writing is on the wall. Xcode integration of svn and git will now provide useful benefits. I also realize that as the third most popular DVCS, Bazaar is unlikely to ever see support in Xcode.

So, with that in mind, I've decided to switch from Bazaar to Git (unless something goes horribly wrong).

The positive news is that so far, the conversion has been about as painless as it could possibly be. Certainly far more painless than the conversion from CVS to Bazaar.

To convert from Bazaar to Git involved the following steps:

1) Install the Bazaar fastimport module

2) Install git

3) Create a git repository into which to convert

git init git.repo - (use --bare if it's going to be on a central server)

cd git.repo


4) Run a command to export the bazaar repository, piping the result to a command to import into git

In this example:

~/bzr_repo - the bazaar repository to convert

~/git.repo - the new git repository


(command is being run from the git.repo directory)

bzr fast-export --export-marks=../marks.bzr ../bzr_repo/ | git fast-import --export-marks=../marks.git

That's it. You're now done. You can now clone that repository and go to work.

Doctors' payments

Does anyone else hate trying to pay their doctor as much as I do?

First, you can never figure out how much you owe them. Typically, a huge bill comes first. But you know you don't owe that much, since insurance is going to cover the majority.

So you wait for your next statement to see what you really owe. But now you're past-due. And woe be to you if you visit the doctor more than once in 30-days; you'll be lost in an impossible maze of charges and insurance reimbursements.

Ok, fine. My doctor sent me a "please pay now" notice, so I'm pretty sure this is what I actually owe. No problem. While I'm sitting here paying bills online, I'll just quickly go to their website and pay online.

Except that they don't accept online payment. Are you freaking kidding me? An industry that has massive trouble collecting payments does not provide a way for patients to pay online? Yep, that's right. Ninety-nine percent of doctors have no way for you to pay online.

I could pay with my regular online bill payment service. However, it seems like I have about 12 different accounts associated with the doctors we see. So it's awfully inconvenient to have 12 different payees in my payment service.

Fine. I'll call them. Oh wait - it's 11 pm and an industry which has trouble collecting payments only has its billing office open from 9-5 on weekdays.

Fine. I wait until tomorrow. I call the business office during their advertised hours and listen on hold for 20 minutes while the voice response system tells me my call is important. After 20 minutes, it routes me to a voice mail box. I leave a voice mail. Four hours later, after receiving no call back, I call again. 20 minutes later I leave another voice mail. Four hours later after no call back, I call again. Twenty minutes of repeated "your call is important to us" later, the system tries to transfer me to an operator, but it hangs up instead.

The business office is now closed for the day. To make a long story a little shorter, after two more attempts the next day, I finally get through and pay my bill over the phone with a debit card.

In short, absolutely unacceptable.

Yes, I realize I could just write a check, get a stamp, put it in the envelope and mail it. However, that's not the point. The point is, I want to pay my bill NOW. Online. And you're not letting me do it.

No wonder you have problems getting paid.

Status of the Mac client

As some of you may have guessed by my lack of posts, the Mac client has basically been stalled. My real-world job has been absolutely crazy, summer means all sorts of kids' activities and I've picked up additional responsibilities at VATSIM.

I have no intentions of abandoning the project though. In fact, I'm considering adding some additional team members to help speed things up. Things I'd likely farm out would be the things that can be easily compartmentalized like alias and POF file handling, flight strips, etc.

I haven't made a final decision yet, but if you know Objective-C and want to help, let me know.

Some network goodness

More & more pieces are coming into place in the Mac client. This week I wrote an Objective-C wrapper around the VVL network code. Good chance by the end of next week I'll be able to login and start testing sending and receiving text messages on the network.

Additionally, it won't be difficult to wrap the voice code either, so it may not be too much of a stretch to get voice working before much longer as well. The Mac voice code all needs to be rewritten as it's still VERY old SoundManager code (yech) which frankly I'm surprised still works. However, it does work, so I'll probably start off with just using it as is at first, so we can get something out the door without having to wait on me to rewrite the code with CoreAudio.

Things are looking up

With the heavy snow (well heavy by our standards) snow in Nashville, the family hasn't been able to get out of the house, so I've had a little more time to sit and program rather than running all over creation.

I've gotten a not completely insignificant portion of the interface wired up with Interface Builder and have moved on to start working on the text windows. This part is going to be a bit challenging since I'm trying to integrate traditional Cocoa controls on top of an OpenGL view. It can be done, but not having attempted it before, it's going to take some playing with.

Some more progress

Nothing too exciting to report, but given the extra time over the holidays, I have been making more progress than I normally can. I've started hooking up some of the user interface items and am working on the preferences dialog.

Still tons to do, but bit by bit it's starting to look like an application rather than just random code.

Time...never enough

I realize it's been a while since I've posted, so I wanted to post something.

Things are going more slowly than I'd like. There's really no technical reason; work has been killing me lately, and with two eight-year-olds around, there's an activity nearly every evening. Most of my development time has been coming in 30-45 minute spurts, and as developer will tell you, it's difficult to work like that. You barely can get your mind focused on where you were when you left off and suddenly it's time to quit.

The good news is the transition of the drawing code to Vertex Buffer Objects (VBO's) is complete. While not necessary for performance, it allows me to avoid a rewrite should the rumored removal of Immediate Mode in OpenGL 3.0 come true.

I'm currently working on figuring out how to set all the colors for all the objects. My hope is to be able to set colors on individual line segments, rather than just a whole class of objects. While perhaps not the most mind-blowing feature, I'm sure people would enjoy the extra level of customization.

Another Windows Beep of Death Fix

A new version of XSB is coming soon, but until then, Windows users need a new beep-of-death fix, so here it is.

Windows Voice Fix

Latest on the ATC Client

Not much to report on the ATC client. I've been working on a new version of XSB and meeting some deadlines for my other project (Targetware), so that's consumed the majority of my time.

I did switch from using an NSOpenGLView to a GLView subclass. This gives a lot more flexibility. The OpenGL context can be on multiple screens, it can have Cocoa controls on top, etc.

Right now I'm in the process of moving the drawing code from Immediate mode to Vertex Buffer Objects. It's an optimization that's completely unnecessary given the trivial requirements of a radar client, but Immediate Mode is slated to go away at some point, so better to change things to use the "right" way now.

I should get some more time near the end of the month to work on the client, and should have good things to report then.

Looking for a web designer

Copied from my post on x-plane.org:

Ben and I are in the process of moving the XSB website to a Content Management System so that I can directly edit the VERY outdated FAQ and other documents. It also will allow me to post new releases without having to take away from Ben's X-plane development time.

The problem is, Ben and I are both programmers, and are absolutely awful as web designers.

So here's your chance to contribute. We're looking for someone who either has experience working with the Drupal content management system, or just has high-quality CSS skills. Additionally the person needs to have good design sense too. Just knowing how to install a web server and MySQL isn't what we're looking for. We're looking for someone who considers themselves an actual web designer and can do crazy things like match colors.

This will likely be a one-time time commitment. That is, once the site is designed and up, there likely won't be anything left for the site designer to do. So it will not require a long-term time commitment. Additionally, we're only talking about a few templates/pages. This is NOT a major design project.

Anyone that's interested, please email me at wade@dogwatchsw.com

http://forums.x-plane.org/index.php?showtopic=39623

Some work on the Mac ATC client

After many months of having no time to devote to the Mac radar client, I had a little bit of time over the weekend.

To properly set expectations on where things stand, right now it's just loading the sector file and drawing it. I had been having problems with zooming and panning that were bugging me, but those have been resolved.

However, despite my warnings of the rudimentary state at which we're at, I can't resist a small teaser:



That boys and girls, is KLAX from the ZLA sector file. (Only airports, runways and geo's are being drawn in this example.) The colors no doubt need adjusting, but any ZLA controller will certainly feel at home looking at that diagram.

So what's up next?

Before I get too far, I need to optimize the drawing routines, so that's probably next. Then I'll start wiring up the interface to allow the enabling / disabling of drawing of all the various sector file elements without having to change code. After that I'll start working on the text system (chat windows and such). Once all that is done, we'll be ready to start delving into networking and making planes move.

Hope for the Linux Sound Bug

I'm traveling to visit some family next week, and when I return, I should have a spare PC in my possession. My intent is to use that PC to install Linux and hopefully track down the Linux sound bug.

I won't return with the PC until June 11th and it will probably take some time after that to find the bug, but at least there's a glimmer of hope on the horizon.

One known fact about the future VATSIM Mac radar client

I announced a few weeks ago on the VATSIM forums that I do have a Mac radar client for VATSIM in development.

In still in the early stages and I don't know whether it will take 3 months, 6 months, a year, or two to finish. There's always the possibility that I never finish it. Now, before I depress you too much, I do think there's a very good chance I will finish it and probably sooner rather than later.

One thing I do know is when published, it will require OS X 10.5 or later. I originally started the project targeting 10.4, but there's just too much nice stuff in 10.5 of which I think I'm going to be able to take advantage - if not in the first version, than in a later version. Things like CoreData for persistent data storage (such as aircraft details), CoreAnimation for creating various layers, fast enumeration and probably garbage collection.

So I want to go ahead and get the word out now, rather than later. Let me say it again - 10.5 will be the minimum.

If you don't have 10.5, you don't have to run out and buy it right now. In fact, I wouldn't. I'd wait and buy 10.6 when it comes out.

But heads up now - requests to make the radar client run on 10.4 and 10.3 will fall on deaf ears.

Delay in posting Linux test version

So, the promised test version has not yet appeared. I did the required coding, but I've been completely unable to test. With no OpenGL support in my VMWare environment, X-plane is just killing my Ubuntu VM.

If you want, you can download and try:

Linux Test Version

However, to be very clear, I'm not at all confident it will work correctly. If it succeeds, it will create a file called XSBLinSoundDebug.txt in your home directory.

I'm working on some angles to get some sort of real Ubuntu machine setup so I can do actual debugging.

New Windows Temporary "Beep of Death" fix

(Whoops - if you downloaded this patch already and the Connect menu was disabled, download it again - I have corrected the mistake.)

The temporary patch I had out for the "Windows Beep of Death" has expired. A new version is posted at:

Windows Voice Fix

The next regular release of XSB will contain this fix.

Linux test version by the end of the weekend

I was hoping to combine the latest XSB update with the additional Linux sound logging code. However, it's taking longer than I wanted to get the next version out.

It's taking longer because I decided to add an additional preference window for a new setting, which allows the user to specify the width of the text window and chat bar. This is especially handy for those using the Matrox triple-head solution, because X-plane sees that as one screen and thus would stretch the text box all the way across all three screens.

The reason a simple dialog box is taking a bit of time is because it's more complex than you might think. Each coordinate of each element in the dialog box must be specified manually. Try to place some things, compile, launch X-plane, test. Move them a little bit, compile, launch X-plane, test. Wash, rinse repeat.

And of course the biggest time consumer is that real-life things are getting in the way, like my seven-year-old son's baseball season.

However, I know Linux users are tired of waiting, so I'm going to go ahead and put up a private download by the end of the weekend for Linux users. It will contain only additional logging code for sound - no other new features.