>We could have the wc record itself every time some svn command accesses
>it -- is this what you plan?

That is potentially expensive and complex, turning a read-only
operation into a read/write one; rarely a good idea. It also
introduces more points of failure.

Otherwise, available options seem to be:

1. Keep strict reference counts (or reverse references) in the shared
base, and tell the user to only use Subversion-approved means of WC
removal, or else.

Variants:
a. Force trees sharing the same text-base to live within a single
hierarchy (Bazaar). Not sure how that helps, other than limiting
the scope for exhaustive search for references.
b. Keep conservative reference counts (that may overstate the need for
each file), and accept a certain leakage.

2. Don't keep reference counts but treat the text-base tree as the
cache it really is, and purge old entries once it exceeds a certain
user-specified size.

Disconnected operation is a minor problem. A command to "please ensure
that this WC is fully backed in my text-base" might work.

3. Forget about the idea, seductive as it is, for now at least.
(And the new WC _will_ be done quicker without holding it hostage to
a shared text-base facility.)