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.