Finger info for icculus@icculus.org...


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.
    

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.24
Stick it in the camel and go.