Finger info for

 Now open source!
 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.

 Interesting note about Apple at ... the latest
 CVS has 5.1 support on OSX. Sweet!

 Latest CVS builds and runs on Solaris/x86 (and presumably Solaris/sparc, too).

 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:

 Linux (x86 and amd64) official 3204 patch (with KIntersect fix!):

 MacOS X (un?)official 3204 patch:

 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:

Postal 2 Share the Pain:
 Linux demo:
 Linux retail: In beta testing (apply at
 Mac retail: In beta testing (no more applications, please!)

America's Army:
 2.1.0 is out for Linux and Mac:

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 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.


When this .plan was written: 2004-06-01 23:20:04
.plan archives for this user are here (RSS here).
Powered by IcculusFinger v2.1.27
Stick it in the camel and go.