MojoPatch: Now open source! http://icculus.org/news/news.php?id=2040 Just added zlib support, since files to be added are copied verbatim into the patchfile, which in the case of the Neverwinter expansion packs, means you could end up with a patchfile that's around a gigabyte. Now I can get the thing onto a CD-ROM, comfortably. Patches from xdelta could use zlib, too, but don't at the moment. Shrek 2: I think we have a Gold Master, but don't quote me on that. It's VERY close, at any rate. OpenAL: Interesting note about Apple at http://openal.org/ ... the latest openal.org CVS has 5.1 support on OSX. Sweet! Duke3D: Latest CVS builds and runs on Solaris/x86 (and presumably Solaris/sparc, too). UTPG: We're bringing in Steven Fuller ("relnev") to do some UTPG hacking. Beyond doing consistently quality work, I expect his mere presence will keep my ass in gear to get the Mac and Linux ports done. Unreal Tournament 2003: Mac 2225.2 is out. Hit the mirrors. I'm going to do a Linux 2225.2 build, since there's about a million little Unix fixes that went into the Mac port that would benefit Linux users...and Linux 2225.0 was a crappy build anyhow. After that, I feel pretty good about closing the book on ut2003 for good. Unreal Tournament 2004: If Mac retail installer crashes on you, use this: http://icculus.org/~icculus/tmp/UT2004-mac-updated-installer.tar.bz2 Linux (x86 and amd64) official 3204 patch (with KIntersect fix!): http://icculus.org/news/news.php?id=2034 MacOS X (un?)official 3204 patch: http://icculus.org/news/news.php?id=2036 Alien Swarm's server browser is triggering a bug in the Engine, that happens to crash Linux clients (but the Mac and Windows people are also touching free()'d memory, they just get lucky in this case). We're looking into it. Call of Duty: 1.4 is out, now with PunkBuster support: http://www.callofduty.com/patch/ Postal 2 Share the Pain: Linux demo: http://icculus.org/news/news.php?id=1816 Linux retail: In beta testing (apply at http://www.linuxgamepublishing.com/) Mac retail: In beta testing (no more applications, please!) America's Army: 2.1.0 is out for Linux and Mac: http://icculus.org/news/news.php?id=2046 Other stuff: Now that I'm using Subversion for several projects, both open and closed, with both remote and local repositories, here are some thoughts on what I dislike about it. I don't imagine any of these problems are necessarily inherent and unfixable, but here they are, fwiw: - I'm not comfortable that svn actually "scales" to big projects. It's definitely sweet for smaller stuff (i.e. - stuff you could handle without question with CVS), but I'm also using it on an Unreal licensee's project. Said project is over a gigabyte, and is stored locally (i.e. - the repository is a "file://" URL). Both source and art assets are in revision control. Bottom line is that some operations are very very slow. "svn status" can take upward of 30 seconds to a minute to run, as do other global things like "svn diff" and a blanket "svn commit". This slowdown isn't there when I specify files..."svn diff main.cpp" is still fast where "svn diff" isn't. I guess this is the benefit of Perforce forcing you to open files for editing first: quicker to track what's changed. I have to be honest, I don't know what the hell I did to a source tree five minutes ago in most cases. I use "svn status" and "svn diff" gratuitously to keep track of my work, and it's really frustrating when they lag. Obviously, on smaller stuff (like the mojopatch repo), these operations are wicked fast. - It'd be nice to be able to limit what is duplicated in the .svn dirs. Of this gigabyte checkout, 9/10ths are art assets that may never be updated at all, let alone by me, nor will they be diff'd, etc. Might be nice to have a unversioned property (or some way for this to be specified per-client) that a given file isn't stored as a pristine copy in addition to the working copy. Then again, disk space is cheap, right? - I REALLY like how Perforce lets you do "p4 submit" without any specific files. When your editor pops up for you to comment your changes, you can edit the provided list of changed files before saving your comments if you don't want to submit them all. Subversion shows you a list, too, but editing it doesn't do anything. I really REALLY got used to this with Perforce. Granted, porting software is different than developing software, as I could legitimately be all over the codebase, touching several unrelated lines in unrelated files for unrelated units of work, which is probably different from someone doing original development. So frequently, I'll do a "p4 submit" and chop out the files that aren't part of the changes I want to submit at that moment. This is very cumbersome with svn, since I need to specify the files on the command line. Frequently I end up checking in a whole bunch of unrelated stuff with a comment like "changed some stuff." - I love that there's a second copy of the repository in your working copy, so you can diff, etc offline. I hate that it's too accessible. For example, I want to see where the "Blit" function is referenced in the code. I run "grep -rn Blit *" in the root of the working copy. I get twice as many results, half in the ".svn" dirs. That's annoying, but worse was when I ran "d2u `find . -name "*.cpp"`" to convert all the C++ files from DOS to Unix endlines, which I had forgotten to do before the initial import. It converted the working copy and the pristine versions in .svn, which causes subversion to panic when the checksums aren't what they expect. Which brings up the next point: - When the pristine files in the working copy don't match their checksum, svn should pull down new pristine files from the repository. At best, this should generate a warning before doing so, but it really shouldn't leave you wondering how to unwedge your local copy. - Committing a change pops up your editor to write "svn-commit.tmp". Since my editor keeps track of where I left a file, my cursor won't be at the start of svn-commit.tmp when I do a commit, which disorients me every time. CVS and P4 just happen to get around this since they chose a random filename in /tmp for each commit. Arguably, this isn't really a Subversion issue, but it still irks me. Maybe svn should choose a filename like CVS, and for failed commits, later rename it to svn-commit.tmp? - Along these lines, I don't like that svn-commit-number.tmp files keep piling up. It's good that I don't lose my comments if the commit fails, but maybe it can reuse an existing svn-commit.tmp's comments if it exists, since it'll automatically delete the file if commit succeeds anyhow, you'd imagine there's probably a good immediate reason the file is sitting there if it already exists when you go to make a commit... - Repositories seem to wedge in semi-harmless ways frequently and inexplicably. The Linux Gaming FAQ keeps their website on icculus.org in a svn repository now, and one day, it panicked on update and told me to run "svnadmin recover", which I did. "Recover" finished in about a nanosecond without any explanation as to what it fixed, but it did definitely fix it. However, it reset a bunch of file permissions (basically all the ones the Subversion Book says "YOU NEED THESE OR SSH ACCESS DIES!"). Locally, I added some svn:ignore properties to a svn repo. When I went to check them in, it told me my working copy was out of date (what? I'm the only guy using a "file://" repo in my home dir!). I ran "svn update". It didn't update any files, but then my "svn commit" worked. Which scared me a lot. These are all issues I've had in less than a week of hardcore svn use. There are probably other things. Some of these are fixable, some are arguably not bugs, but this is my current feelings on switching from CVS and Perforce. --ryan.