Git: It *could* be harder.

Some time in the last two weeks, I pulled some code from somewhere, made some changes, and dispatched them to the author for review.

Then I scratched my head. I’d just used git.

‘Neato’.

Workin’ Mercurial

On Friday I used Mercurial‘s built-in repository conversion tool to build a Mercurial repository from Subversion 1.30 branch. Went home, cloned that to my Linux and Windows boxes and I’ve been tinkering over the weekend.

With the inotify extension, it’s really zipping under Linux; especially with atime changes disabled.

And I notice that I’m very quickly falling back into the habit of early commits.

The only bottleneck in the system is that the master repository is on a Windows Server 2003 share, and cloning/pulling/pushing are a little slow. I suspect that I need to look into setting up hgservice or something.

But if we do switch to Mercurial, I think we’ll probably set it up alongside Trac (which I increasingly dislike) or Redmine or something: Trac development seems somewhat bumbling, Redmine is generally nicer but it has rude rough edges – e.g. the forum system is kinda noddy. I will probably like Redmine more when I quit trying to integrate it to our Windows domain logins and use our game-database logins like we do with Trac right now.

Git: A review by a not-gonna-use-it-er

This is in response to Drave and Xiper’s questions about my nixing of Git as an option for a replacement version control system.

“Git” is an incredibly popular distributed version control system originally developed by Linus Torvalds, creator of Linux. The fact that it is used by the Linux Kernel development team has given it a firmly established base in Linux development. Add in the “github” project hosting service and it has stealthed into the position of dominant “revision tool thingy” that RCS once held.

“Mercurial” is another popular distributed version control system, lurking in the shadows.

So why did I nix Git and start looking more at Mercurial?

Thinking to 1.32

1.31 (or the lack thereof, as yet) has been almost as frustrating for us as it has for our players. It is likely to become known as the “if I’d known that” patch.

I’ve been wholly mired in cell host performance issues for a while, stuck in the maw of code that I really, really, really hate. Code that resists or springs a leak at every turn. It is the code that any sober refactorer would say rewrite to.

But it’s not just some subsystem, or some corner of code. It’s the fundamental basis for the cell host.

Inconsistent Line Endings

If you’re using Subversion and you get a problem between two branches with “inconsistent line endings” you may be in for a world of hurt.

SVN: 4 weeks in

Generally finding the switch from Visual Source Safe to SVN a boon, but there are definitely some areas where it’s weaker than you’d expect. In particular, we’re running into a few simple ball breakers:

Line Endings. Oh. My. God. When we populated the repository, we didn’t even think about this. Get this, using the Microsoft version control solution it wasn’t an issue. Ha – who’d think the first point for VSS vs Open Source RCS would be a cross-platform issue? (Anyone with coins inserted in their brain meter)

So, none of our files have svn:eol-style native. That’s the fix. But if I svn propset svn:eol-style native */*.cpp */*.h there’s just one minor itty bitty niggle: it changes every line in every file completely destroying history and blame.

Start or Pre commit hook?

As part of our automated build process, I provide a list of branches/versions that can be compiled. With Visual Source Safe I just wrote a script to use the SourceOffSite client and read all the versionNo.h’s from certain folders and generate an XML file. With SVN it seems like I could improve on that by making it so that any commits of “versionNo.h” would automatically set a property on the top-level folder and then my build tool could just read properties rather than having to fetch versionNo.h from each folder and scan it.

Only I’m new to SVN so … Would I do that client side or in a start commit hook or a pre commit hook?

Subversion

Well, we went ahead and did it; switched from Visual Source Safe to Subversion. Ahh. The producers see TortoiseSVN and want it, so our data will be going over soon too. Right now we’re running VisualSVN server on our Windows file server and their client for Visual Studio.

I’m now trying to set up commit hooks and running into brick walls. I wanted to avoid having to write something myself and though the Ruby commit-mailer.rb sounded promising. Except, it appears that Ruby no-longer ships with ruby-svn and I can’t figure out where the heck you would get it from.

So, I guess I’ll do something with the Perl version. That’s not so bad, really, I can make it announce commits to the IRC server while I’m at it :) Or, more likely, have it write the announcements to a database and let something else pick them up.