5.3.17 (well, cvs update at announce time, really) seems to work on
the client side (haven't tried server).

<rant>

This release has changed the venus rvm format once again.  This time,
it seemed to happen without being announced.  These changes cause all
that valuable hoarded and cached data to be discarded, and it takes a
long time to hoard 100 MB or so over a 28.8 line.  (I didn't lose
data, since I know to check for no CML entries before upgrading.)

</rant>

Constructive suggestions:

1) Always make a note in ChangeLog when an incompatible change is
   made.

2) Create a NEWS file in coda and put things like this in it.  rvm
   format changes requiring -init are perhaps the biggest form of
   user-visible changes.

3) always send a note to codalist whenever such a change is made, so
   people can work around this (only upgrade when high bw or a long
   time will be available for hoarding).

4) (the hard one): Create a venus_dump/venus_restore program that
   emits/reads venus state (both metadata and data for all objects in
   venus) to/from a stream.  Then someone could do 'venus_dump > foo',
   rebuild/install/-init and venus_restore < foo.  This could also
   be used for prefilling venii caches.  Basically the metadata would
   be the fid, vv, storeid, etc.  It might be that some files when
   restored would be old, but it would be just as if a venus had been
   off-net for a very long time and came back.  Things still valid
   would pass ValidateAttrs, and things that aren't would fail and get
   flushed.   But all those 2 MB tar files that hadn't changed
   wouldn't need refetching.  (I've previously said that this format
   should be BSD4.4 dump for data with metadata in funny names, but
   even with a private format this would be very useful.  Perhaps I'll
   get some spare time, but I wouldn't count on it.....)

5) (the perhaps really hard one) Perhaps separate out metadata and
   cache info from the other stuff venus stores, so that the
   metadata/cache format doesn't need to change so often.

Sorry to flame, but as I am relying more and more on coda, this
problem is getting more annoying.  It wasn't too bad; I was going to
use the drive-the-disk-to-work method of bit transfer today anyway
(with a 30 GB disk and a 40 minute drive, that's 13 MB/s...).
The good news is that I am getting away with relying more on coda; I
actually have my main work files in it right now and do RCS in
write-disconnected mode over the 28.8 line and it works!

        Greg Troxel <gdt_at_ir.bbn.com>