On Mar 3, 2009, at 8:36 AM, Magnus Torfason wrote:
> I have to think about svn blame. Are you saying that "svn blame"
> should continue to return the same output as before the obliteration?
Sorry, no, not particularly. I was using "svn blame" as a short hand
for "infinite knowledge about the ancestry of every byte in every path/
rev," and specifically using it to describe our knowledge of the repo
just *before* the obliteration. Guess I over-simplified my wording a
mite. To restate the paragraph without mentioning "blame,"
[In the disc-space story,] we want to remove the space no longer in
use for any path/revs that should remain available post-obliteration,
but the space that makes up some ancient delta which is still in use,
post-obliteration, we should not remove. That is: a post-obliterate
checkout of path_at_HEAD should show the same result as it did before
obliteration, even if the post-obliteration checkout includes some
text which was introduced into the repository during some now-removed
revision.
That is, I was drawing the distinction between the "security" story,
which wants to remove *information* even from current versions, and
the "space" story, which wants no change in current and near-current
(that is, post-obliteration) checkouts.
Or, to point up the difference in another way:
- "space" wants to save disc space, requires no change in recent
revisions (and working copy continuity), and is willing to sacrifice
invariance of checkouts of older revisions.
- "security" wants to remove information, requires absolute removal
throughout all revisions, and is willing to sacrifice working copy
continuity.
It's remarkably hard for me to think of these two things as the same
operation! I would call the "disc space story" something else,
"archive," because as a practical matter all our customers keep asking
us for this function, and they always call it "archive." I would leave
the name "obliterate" for the "security story," because though
relatively few of our customers ever mention this, when it comes up,
that's the sort of term they use for it.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jackrepenning
twitter: http://twitter.com/jrep
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1269073
Received on 2009-03-05 00:05:18 CET