> A TWO-BY-TWO CLASSIFICATION OF OBLITERATION TYPES
> At a high level, obliteration can be classified along two
> dimensions. The ABSOLUTE vs. VIRTUAL distinction refers to whether
> obliterated data is removed from disk or merely hidden. The
> OFFLINE vs. ONLINE distinction refers to whether working copies
> can continue to be used after an obliteration operation.
Oh, there are more dimensions than that.
- Does the obliterate function affect a file and its entire history, or
does it simply "flatten" two revisions into one-plus-a-noop? The
latter seems like it might be easier, and would be perfectly acceptable
in the common case where a rev was immediately reverted.
- Is it OK for there to be evidence on the server side that a deleted
file previously existed? (For the VIRTUAL case, obviously yes, it is
acceptable.) Which characteristics - pathname, size, checksum, etc. -
are acceptable to retain? Or does it all need to be wiped clean? This
may sound like a petty detail, but it has important implications for
gracefully handling affected WCs.
- Should a server attempt to "fix up" an affected WC? This is probably
possible if the client is obliterate-aware, i.e., 1.7+ or whatever, and
depending on the answer to the previous "dimension". Probably not
possible for svn 1.0 - 1.6 clients. (And then there's the question, if
the server tells a 1.7+ client to obliterate its copy of a file, what
to do if the file is locally modified - but that is a detail.)
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2009-02-26 19:38:46 CET