>>>>> "Satya" == M Satyanarayanan <[EMAIL PROTECTED]> 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.
