>>>>> "Satya" == M Satyanarayanan <satya_at_cs.cmu.edu> writes:

    Satya> One very early design choice we considered (but rejected)
    Satya> was to simply pin objects in the cache via hoarding. [...]
    Satya> One reason for rejecting the "sticky" approach was that we
    Satya> didn't have a good answer to the question of what to do if
    Satya> the resync step would cause a pinned subtree to expand
    Satya> greatly (beyond cache size limits).

I've experienced this; I had a project under CVS control that was
consuming about 80% of a 50MB cache.  After a few weeks of CVS
and editing operations, I'd accumulated a bunch of Emacs foo~ backups
(which I had a pretty good handle on), but even more "dark matter" in
the form of cvs .#foo-1.2.3 files.  Oops.

Maybe something a little more complicated than a simple "pin", such as
dedicating an allocation of cache space to a subtree?  Up to that
amount of space the files are pinned in the cache.  This would have
worked fine for my situation; I would have done a hoard walk before
disconnecting, hoard would have told me that tree didn't fit, and I
could have cleaned it out.

Alternatively, in my case a .coda_ignore file would have been fine.


-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.