[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: <kmradke_at_rockwellcollins.com>
Date: Mon, 21 Apr 2008 09:55:55 -0500

Branko ╚ibej <brane_at_xbc.nu> wrote on 04/21/2008 01:13:42 AM:
> Karl Fogel wrote:
> > Branko ╚ibej <brane_at_xbc.nu> writes:
> >
> >> Yes, that's the can of worms I was talking about. But there aren't
> >> that many options; we either keep an empty revision (i.e., no
changes,
> >> just the elision record); but IIRC that causes all sorts of other
> >> problems; or, we put the elision record on the previous
> >> revision. (Previous because it always exists -- we can't obliterate
> >> revision 0.)
> >>
> >> However it wouldn't hurt to investigate if we can, in fact, leave
> >> empty revisons around after an obliterate. That would be most useful
> >> in general because existing revision numbers would remain valid, and
> >> the need to re-check-out a zillion working copies would almost
vanish.
> >>
> >
> > We will definitely want to support the use case where the revision
> > number itself has to go away. People may not use it very often, but
> > when they want it, they really want it. However, that's also a case
> > where keeping a record might not be necessary anyway!
> >
>
> Possibly ... but I'd really like to see a rock-solid argument for the
> case where we'd want all traces of obliteration ... er, obliterated. The

> whole idea smells wrong; after all, this is a version control system,
> not a document shredding system.

For most of my use cases, I think leaving an "empty" revision with
some type of audit trail is preferred. (Things like sensitive
info being checked in.) We don't care people can see the event
happened (in fact, it may be illegal to "hide" the fact it did
happen), but the actual contents can no longer be retrieved.

However, worst case is the comment or even the file name itself is
somehow sensitive. I would hope this is fairly rare (and it could
still be handled with a dump/reload).

Another use case is that an user checked in something large and stupid.
(Yes, I've seen many DVD .iso files...) A simple way to just get rid
of the 4G+ file would be nice. (Dumping and reloading 50G+ repos
in painful...)

On a side note, it has always bothered me that changing revision
properties leaves no audit history trace... Does this bother
anyone else?

Kevin R.

---------------------------------------------------------------------
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-22 08:56:16 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.