Global Ignore All The Files!

One thing about source control is that you can get a lot of cruft in your repository (sounds naughty).  Since I am (at least as far as using it for something important in a professional capacity) new to Subversion, I had to deal with that problem today.

A couple of deleted repositories later and I think I have it all tuned.  I found a nice page on StackOverflow that had a good list of file globs to add to Subversion’s global-ignore configuration item.  I had to add a couple of extensions that I have been using for years in my various endeavors (*.out as an example) and now I think my configuration covers C, C++, C# and Java’s worthless effluvia.

Well, the Java case is a bit sketchy.  It seems that ignoring the bin directory pretty much leaves Subversion to get only meaningful Java stuff during an import or a commit. Subversion still indulged in some weirdness though (probably because I did something weird).  I will have to keep an eye out for junkfiles.

I have experience with Visual SourceSafe and ClearCase in a work environment, and luckily I didn’t have to do much with their actual administration parts.  After a while you kind of get how versioning systems are supposed to work, and I think that starting with something as dead simple as SourceSafe and then moving to ClearCase was a good thing.  ClearCase is high octane and would have been too much for us as a team to deal with on day one in the blessed land of source control.  But having been in the ring with ClearCase (and lost many metaphorical battles) going to Subversion now has been relatively painless.

My favorite thing about Subversion is that it has encouraged me to use branches as they are intended, something that is a little obscured in ClearCase (at least the way we used it). I hope I have the comparisons correct:  a VOB is like a repository, and a view is like a working copy.  So working in a branch in Subversion is like having a view that you will eventually discard or merge into the main path.  We actively did not keep a lot of views around because of server storage space and the pain it took to make them (even though I pretty much used snapshots myself rather than dynamic views, which is nearly the same as a working copy with Subversion, except for the annoying read-only files).  With Subversion all of this is extremely streamlined and seemingly more integrated into Subversion’s design.  Getting a branch is a checkout away.

I guess ClearCase is meant for different (perhaps insane) things developers attempt, which is why dynamic views are the real shiny nubbins for that product.

So even though it is just me developing things for now, I am going to get into the habit of working in branches and merging to trunk like a good boy.  I always just worked in trunk during previous forays into Subversion, but now it is best practices, best practices, definitely best practices.  A little luck and I may need those practices.

I am rustier in Java than I thought, so I spent a little time going over some of the weirder parts of the language.  One of my favorite occasions this year was a lazy Saturday and Sunday playing Crawl with a video stream of Notch writing his Ludum Dare entry Prelude of the Chambered on the other monitor.  Yes, that is what passes for fun for programmers.

It was (nerdily) cool watching an expert rush through the development of a pretty impressive game for the 48 hours (or so) it took to write.  The most interesting thing was some of the weird stuff I saw him do, like this little bit of magic:

public static Sound loadSound(String fileName) {
    Sound sound = new Sound();
    try {
        AudioInputStream ais = AudioSystem.getAudioInputStream(Sound.class.getResource(fileName));
        Clip clip = AudioSystem.getClip();
        clip.open(ais);
        sound.clip = clip;
    } catch (Exception e) {
        System.out.println(e);
    }
    return sound;
}

private Clip clip;

public void play() {
    try {
        if (clip != null) {
            new Thread() {
                public void run() {
                    synchronized (clip) {
                        clip.stop();
                        clip.setFramePosition(0);
                        clip.start();
                        }
                    }
                }.start();
            }
        } catch (Exception e) {
            System.out.println(e);
        }
    }
}

This is part of his Sound object that plays the various effects for in-game events.  I hadn’t done anything with sound in Java before, and while this is simple, doing the same in C++ sure takes a lot more lines.  At least in Win32; creating a bunch of events and mutexes to synchronize a thread (and writing the thread code, not to mention the actual sound library stuff) makes for a lot more code.  The bit that Notch wrote here is pretty compact.  I watched him write this in live detail and the first few tries didn’t work, so I don’t know if he had the general idea in his mind (e.g., the sound routines from Minecraft!) and he hacked away at it or if he peeked at some old code to get a good method.  Is this real code from somewhere else? If this is all Java production-level code needs to do at-least-usable sound effects, I think that’s neat.

By the way, the most painful thing about watching Notch work was how there are no comments.  I know he was on a nuttily tight schedule, but he went fast enough that it was a little too easy for him to leave commenting behind.  I shouldn’t count this as a good example of his work, even though I can’t help it; I hope Minecraft is well commented and maintainable.  I have spent the last five years beating commenting habits into myself, so it is compulsive at this point (compulsive is right…I am still terrible at it, and I make some of the most worthless comments you can imagine, but I can’t help it.  It’s either this way or no way!).  I wanted to at least write something about what he was doing for the above routines.  Best practices, definitely best practices.

Another aside:  I am very happy with Eclipse’s current incarnations nowadays.  It’s been a while for me and Eclipse, and the maintainers have made it into an impressive development environment.  As is obvious, it really shines when writing Java.  Most of my previous Java work has been a DevStudio→javac→java-type workflow, so it was clunky with no real debugging (just messages to the console, really).  Now that I am taking on a much larger scale Java project, I am really grateful that something like Eclipse exists.  But I am sure I will find more to complain about with Eclipse in the coming months (I sure miss virtual space!).

Leave a Reply