Re: Obliterate and auditability

On Sun, Apr 20, 2008 at 5:40 PM, Branko Èibej <brane_at_xbc.nu> wrote:
> Karl Fogel wrote:
>
> > Branko Èibej <brane_at_xbc.nu> writes:
> >
> >
> > > 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. :)
> > >
> > >
> >
> > I'm fine with that, I just don't know how to handle the case where the
> > obliteration is *of* a revision.
> >
> >
>
> 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.

If we change revision numbering you also will need a process that goes
through and updates svn:mergeinfo accordingly.

What if obliterate always left the revision, and then appended to
comment for that revision what it did? That could be the audit trail.
 For example:

Normal log message.
* file
 etc..

++++ Revision was obliterated.
  User: johndoes Date: 2008-04-20 11:45:12
  /trunk/private/password
  /trunk/private/certs

Something like that?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/