gstein_at_tigris.org writes:
> --- trunk/notes/wc-ng-design Mon Sep 15 04:22:30 2008 (r33074)
> +++ trunk/notes/wc-ng-design Mon Sep 15 04:33:54 2008 (r33075)
> @@ -683,6 +683,16 @@ keyed/named by the MD5 of the file. The
> appropriate mappings, content/compression types, and refcounts for the
> base text files (for the shared case).
>
> +When the metadata is recorded in a central area (rather than the WC
> +root), then it is possible for the metadata and the base files to
> +become out of date with respect to all the working copies on the
> +system. We will revamp "svn cleanup" to re-tally the base text
> +reference counts, eliminate unreferenced bases, verify that the
> +working copies are still present, ensure the metadata <-> WC
> +integrity, deal with moves of metadata from central -> wc-root (can
> +happen if somebody rm -rf's the wc, then does a checkout and wants the
> +metadata at the wc-root (this time)), and other consistency checks.
> +
This implies bidirectional knowledge:
1) a working copy W knows where its text bases are
2) a text base T knows where its working copies are
(1) obviously has to be true. But if (2) is true, it implies that
$ mv some-wc-root new-wc-root
would leave metadata dangling, because although new-wc-root would know
where its metadata is, the metadata can't possibly know where
new-wc-root is. At least until someone does some svn operation in
new-wc-root.. but even then, how would the metadata know that
new-wc-root is a rename of some old wc, rather than a copy of it?
This may just mean that 'svn cleanup' can't do everything we want it to
do, and maybe that's an okay price to pay. I just wanted to point out
the problem.
Reference-counting is hard; let's go shopping :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-15 17:30:23 CEST