"Bob Jenkins" <rjenkins_at_collab.net> writes:
> 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.
Sure. Would a logfile-type breadcrumb trail be auditable enough for
these purposes? That is, a text file in the repository that records
obliteration events in some standard, loggy format. Except when you run
$ svnadmin obliterate --no-record ...
...then it doesn't even record anything in the log file.
Having it be a plain file leaves admins free to simply go back and edit
the file if they ever need to. Which of course is something they could
also do to anything we record -- I'm just proposing a log file because
it's really easy to fit it into the implementation I already described.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-19 00:50:43 CEST