Mystcraft 0.11.11 and LookingGlass 0.1.0

If you’ve not already seen LookingGlass, you should probably check it out.

I’m releasing the first public API for LookingGlass. The source code will go open source very soon, now, but I want to make sure it’s clean first.

Mystcraft got some really cool features this week as well, particularly age recycling. Check out the change log for more information.

Note that all existing versions of LookingGlass will be effectively useless moving forward, as they didn’t have the API done. The versions of Mystcraft built at the time will only be able to use those versions of LookingGlass as well, so to be able to use the newer LookingGlass builds (with Mystcraft) you’ll need to update Mystcraft. From this point forward the API should remain fairly stable; no loss of existing functionality.

I’ve moved my downloads over to CurseForge.
LookingGlass is available from CurseForge.


Check the Mystcraft Forums for updates and the change log.

We’re not gonna make it, Cap’ain!

I have had something every night this week, most of them deadlines and/or very late running activities. While, for the most part, I’ve really enjoyed these things, this has cut into my dev time.
Normally I’d recover on the weekend, but this weekend is similarly busy; events all day, everyday. I won’t even be home until Sunday night.

So, the purpose of this post is a forewarning to a probable lack of builds this weekend. I know everyone is eagerly awaiting the LookingGlass API, but it’s no use to anyone if I release it half baked. Particularly without enough javadoc.

I *might* be able to push builds early next week (Monday or Tues), but I’ll probably just hold off until next weekend, effectively skipping this week.

Sorry for the gap. I hope to not make a habit of this. I’ve managed pretty well thus far, since starting my weekly release schedule.

Version Control

For a long time I’ve used Bazaar as my version control system. I’m sure that people have lots of opinions on this, but let me present why I chose this:

  • I wanted to be able to put empty folders in the repo.
  • I particularly liked the automatic rename detection in Bazaar. It does better than most other VC systems in that regard.
  • It was simple to use.
  • It’s fast.

There were probably other reasons, but those are the main ones in terms of practical reasons.
However, the main reason I chose it was I didn’t want to choose the other options.

The other options I considered were, of course, Git and Mercurial.
I didn’t want to choose one because I didn’t want to be seen as taking a side. Amongst a number of people you’ll find some interesting arguments over which one is better. I always find “my tool is better” arguments to be rather silly, so I opted out of them by opting for a different tool entirely.

Let’s discuss them a bit, before I get to my main point.

I’ve read a post about how Git is MacGyver and Mercurial is James Bond. I found the analogy quite apt (especially since they are both prone to making things go boom, so it’s fair).
Particularly, Git is complex; everything has it’s own tool or command and it’s a ridiculous Swiss army knife of gizmos which you pretty much have to be an expert to work with consistently. However, if you CAN work with it well then it’s really powerful.
Mercurial, on the other hand, takes a more monolithic approach; it’s got some nice gadgets for when you really need the laser watch, but it doesn’t expect you to use the laser watch on a daily basis. Instead, it gives you the core set of tools which will generally keep things running smoothly. It’s slick, fast, and likes its drinks simple.

This is as it should be, really. This is how they were designed.
Git was designed by an expert for experts. The expert in question didn’t think much of non-experts, so he didn’t care that it was complex.
Mercurial was designed to be fast and smooth. Nailed it. Mostly, anyway.

Bazaar… is just kind of there. I’m not sure what their main motivation was for creating it, but maybe Canonical just wanted their own version control system. Microsoft made one too, so it’s not unprecedented, but at least Bazaar works.

At any rate, back when I was choosing a version control system to graduate to (from SVN… *shudders*), I did my research… and while I found the above analogy good, I was completely disillusioned with either Git or Mercurial due to all the online arguments. I chose Bazaar.
By most comparisons, the three are nearly identical for basic use. They diff, they branch, they are distributed, and they are pretty much the same speed for most operations.

Now, years later, I’ve used both Bazaar and Git first hand. I have some new opinions on the matter.

This past week I was in Italy for a code camp with my colleagues (from various countries), and it turned out I was the Git expert. I found this funny, because I know Git from working on Forge.
However, I was also pushed into the role of fixing the repos and getting everyone working happily on their branches. This included some interesting and serious stuff that I hadn’t had a lot of practice with. I knew how to do it, roughly, but I’d not done it everyday for a week before.
I’m now pretty confident that I AM a Git expert…

And I like Git, suddenly.

Previously, when working on Forge changes, I’d always find Git slightly painful. It worked, but, in terms of version control systems, it’s the most likely to break. Or do something weird. Or eat stuff. Or produce nasal daemons (look that one up; you won’t be disappointed).

So, now I’m considering moving my personal repos from Bazaar to Git. The biggest thing is I’ve taken to certain features such as the branching mechanics of Git (especially the visualization and rebasing). The visualization features actually make it really rewarding (to me) to make branches. I know, I’m weird, but what can one do?

However, one of my original gripes with Git still exists: You cannot put an empty folder into the repo. This is because Git has no concept of file hierarchy; the names of the files include the hierarchy implicitly. This means renaming a folder actually is renaming all of its contained files individually. There are tricks to force a folder into the repo, but it requires creating dummy files, which is against my rules for repos, and it still doesn’t solve the renaming.
Git’s concept of a file is also a bit different, as Git considers changes, not snapshots or files or folders. This is where the limitation comes from. I admit that the tradeoff is pretty worth it for the underlying mechanics, though.

Some of my projects are going to need to migrate anyway, so I’ll do those and see how that goes. Bazaar includes systems for conversion to and from other version control systems, so that’ll make it easy. Now that I think about it, that option was one of my original reasons for selecting it.

Long post for something most people won’t care to read about, but I hope you enjoyed it. Let me know what you think! 🙂