(...or, JM updates. Finally.)
So, I've been terribly busy with Real Life that I haven't had the time to update this little corner of the web. (For the insatiably curious, I've had countless opportunities to update— just not the time to sit down and do so.) For those who don't interact with me in any form or manner (i.e. those who probably wouldn't give a damn anyway), here's a list of what I've been up to lately, in the usual bulletpoints:
- I'm busy working for this wonderful company— this blog is in fact aggregated in the company Planet, along with my wonderful cow-orkers;
- ... Which also means that I've stopped school for the meantime— juggling the two is insane (I've tried it before, and it is not very conducive to either work or studies, at least in my case);
- I'm definitely a year older, and will be another year older still this coming June;
- We bought a new desktop PC for the house, my specs, my choices— a 2.6 GHz Pentium D, 512MB RAM, nVidia GeForce 4400, 160GiB SATA, and a 19" widescreen LCD monitor. With Linux installed, of course;
- On a related note, we moved houses. I no longer live in Las Piñas. I now live on the border of Las Piñas and Paranaque. Hah. Seriously, we moved houses, but we didn't move very far;
- I have a pet, a mongrel pup I've deigned to name Ronin. (My sister wanted to name him Bernie, and there was one cousin who wanted him named Pringles, for what it's worth);
- For the uninitiated, I have a girlfriend, and we've been together for more than a year and a half! :);
- I've been to Baguio for the Christmas break, just like (almost) every year;
- I've discovered the utility of sleeping under cubicle desks;
- ...Primarily because I've been assigned to a project where that utility is one of the few things keeping me sane. That, and playing with Butch's, Glenn's and Clair's balls— stress balls, that is. (Shame on you for having a dirty mind.);
- On a more geeky note (elaborated below), I heart Git and now use it over Subversion for my personal projects and what-not.
So, I was saying something about Git. Details under the LJ cut, for those inclined.
Basically, Git is one of those things that just makes sense for me. Why didn't I use this before?, I kept asking myself. I never quite grokked distributed SCM before, but after actually trying Git out, I was blown away. I first tried it out on a personal project (which I may speak of in the future, if I can get an actual running prototype done), and was simply blown away primarily by the size of working tree— it was way smaller than an equivalent Subversion working copy or repository and it had the whole history of the project right there with the working tree. The whole history. Damn.
What got me started on the road to Git was a blog entry by X.org hacker Keith Packard on repository formats/layouts. He basically made a case for Git vis-a-vis SVN, and what he asserted made sense; I disagree with some points of his, but the gist I agree with.
- Git provides better conflict resolution and merge tools. Definitely. Merging branches under SVN is a pain, and merge point tracking is still a TODO feature in SVN.
- User interfaces are fixable; repository formats are not. Fixing the UI is easy— but starting from a "broken" repository format means that the breakage of that format cascades downwards, and one cannot move away from the format easily.
- SVN's repository format is essentially broken. Having each revision diff as a file (under the FSFS backend) means that damage is propagated downwards across files. It also means that corruption is not easily detected. Git mitigates this by using SHA-1 hashes as object identity, meaning that corrupted objects are easily detected when read.
- Git wins in terms of size. When Keith Packard compared an import of the Mozilla CVS repository into SVN and Git, Git outshined SVN in terms of repository size. The base CVS repository was 2.7GB; the SVN tree bloomed to 8.2GB, while Git tree shrank it down to just 450MB. To quote Keith Packard: "Given that a Mozilla checkout is around 350MB, it's fairly nice to have the whole project history (from 1998) in only slightly more space."
What got me really hooked was a recent release of Git, which contained git-svn(1), allowing bi-directional operation between a Git working tree and an SVN repository. Which meant that I could turn myself into the company guinea pig and test Git out, while still being able to work on our projects (where we use SVN as our SCM of choice). I've tried it out on my current assignment, and I was simply amazed by the fact that:
- I could now (almost) work while at home— the project's SVN server is located at the client's premises, walled-off from the Internet at large, which means that we had to be at the client site to check in code. With Git and git-svn(1), I could work on some code, check it into my Git tree (preserving history), and sync with the SVN server once I get to the client site. Almost, because I can't run tests or even run the app— the webapp has a dependency on a large Oracle database we have installed at the client's premises;
- I can make commits of finer grain. With SVN, I'm forced to make commits that are coarser-grained. For example, I'd want to check in a test even though I know that it'll break the build or will run red (because I haven't written the class or classes the test depends on, or haven't added in wiring in the Spring context files), primarily to preserve history— I can go back to the log and see when I wrote the test, and so I know I can back out just that change when I need to, say when I find out that I don't need the test for some reason, even after writing the class the test was supposed to run against;
- I can work on multiple lines of development (i.e. multiple branches) without worry. With SVN, one would normally create a branch in the conventional branches directory in the repository. Merging under SVN, however, is a bit of a pain— SVN doesn't yet keep track of merge points or branch points, so when doing an 'svn merge A B' one has to specify the revision range manually. So, keeping track of trunk in your SVN branch is also a (relative) pain. Also, I'd often want to work on several things at a given time: I'd probably be refactoring the build files at the same time as working on a bug fix, and I don't like to check in the build file refactorings until I've tested them properly, so a branch would make sense here. Git makes it simple for me to do that.
- Related to branching, Git comes with gitk(1), a graphical browser for browsing the history of a Git tree. With gitk(1), I can see where a tree has broken off the trunk, so to speak, and where branches merge
I had been previously of the "distributed is not for us" mindset, but am starting to think in terms of more hybrid, middle-ground solutions. Git + git-svn(1) is one of those solutions, and I believe that even if your team uses an SVN repository, team members will benefit from using Git for their own trees.
Previously: Stupid IE