[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Obliterate and auditability

From: Branko ─îibej <brane_at_xbc.nu>
Date: Sat, 19 Apr 2008 13:18:44 +0200

Karl Fogel wrote:
> "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.

Frankly, ugh, yuck. This means you have to go outside the repository to
get the complete history of what happened to the repository. That's
somewhat ... not quite there. I'd much rather have such audit info
recorded in carefully selected revprops, for want of a better place; and
yes I'm aware of the can of worms. :)

-- Brane

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 13:19:06 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.