I see that this topic has once again surfaced thanks to Karl. And it is
a logical feature to consider. I wanted to provide my own perspective on
what I think Subversion's approach should be to this request and as a
result add what I believe to be a valuable additional requirement.
I realize that today the ability to permanently delete anything comes
from a manual manipulation of a Subversion dump file. That is a fairly
extraordinary effort to go through, but one that can be automated and
improved upon via something like what has been proposed. That said I'd
like to see the concept of auditability be a requirement in any
potential formal obliterate feature. In proposing that such be a
requirement I recognize that manual manipulation is still going to be
possible, but that's always possible for a version control when someone
has the right access and knowledge.
One of the key purposes for any version control tool is to provide the
historical record of what happened, to what, by whom, and what did they
say about it. The recording of that data is central to providing an
audit record as to what has happened historically to all the contents of
the repository. Many industries and individual companies are required to
be able to provide such audit data whenever it is requested. That calls
for an immutable system. On the other hand, there are distinct times
when something should not be retained. Most obvious are the situations
where proprietary or objectionable content is involved. That calls for
the ability to eliminate any record of that data. However, support for
the later use case compromises the credibility of the first use case.
Nothing can guarantee that the obliterate action is being taken only for
situations that fit the criteria listed above and therefore, potentially
important audit data can be removed as though it never existed.
That's the situation that almost all existing version control tools find
themselves in. I've long since found it funny to hear how auditable
ClearCase is when it has functionality to delete versions as well as
paths themselves. That doesn't promise true auditability. One can point
to process controls as the way to limit access to the functionality, but
they can't really guarantee how such functionality was used.
What I'd like to see with Subversion obliteration is more of a middle
ground. I understand the need to occasionally remove objects from being
viewed historically, but I also strongly value the need for complete
auditing. That leads me to propose that obliterate be able to remove the
contents of files historically, but leave breadcrumbs that note that
something existed at this path at the historical points where it existed
and also provides the information on who removed it as well as the
reason they provided in doing so. I realize that such a solution is much
more complex than what is currently being proposed, but I also believe
it can be a key differentiating feature for Subversion in more
accurately satisfying a true base requirement of version control.
I've discussed this approach with enterprises for a couple of years now
and it resonates well with them so I think it's a requirement (not
necessarily a set approach) that needs to be seriously considered as the
community moves towards any formal support for obliteration.
Gosh I write long e-mails - sorry about that.
Regards,
Bob Jenkins
Practice Manager, Subversion Services
www.collab.net <http://www.collab.net/>
Office: 770.977.5508
Cell: 678.296.0491
Received on 2008-04-18 22:55:38 CEST