On 3/4/2009 6:04 PM, Jack Repenning wrote:
> [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.
I agree 100%.
> [...] the "security" story, [...] wants to remove *information* even
> from current versions.
>
> ...
>
> - "security" wants to remove information, requires absolute removal
> throughout all revisions, and is willing to sacrifice working copy
> continuity.
This is very true. I'll admit that the "security" story is a bit
further from my day-to-day reality than the "disk-space" story.
However, I've been working on a writeup of a use-case that I
envision, along with the work flow to resolve it using what's
in the functional specification.
I hope to post that in the relatively near future.
> 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.
I get where you're coming from. I think the idea is that since the
two both involve changing old revs in the repo, they belong together
in implementation, even if that would not rule out differing
user interfaces.
However, even in the disk-space story, data *is* destroyed
(imagine a file that was deleted because it was not useful at the
time, and "hey, it's all in subversion, so I can just keep my
directory clean without having to worry"). Someone naively running
"svn archive" and then wanting to restore an old file might be in
for a nasty surprise.
Best,
Magnus
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1273982
Received on 2009-03-06 16:39:37 CET