[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: Gavin 'Beau' Baumanis <gavin_at_thespidernet.com>
Date: Mon, 21 Apr 2008 12:31:38 +1000

Hi Everyone,

I know I am a little green...

So bear with me.....

I know there is technically nothing stopping me from re-adding / re-
committing an obliterated resource...
However, is there any value to use something along the lines of Mark's
log details, (some sort of obliterated Listing / flag, perhaps)

and provide a warning that the new resource previously existed but was
obliterated?

I realise, It is simply going to be easier - to re-obliterate the
resource again if subsequently added in error - but in the interest of
user-friendliness...

Beau.

On 21/04/2008, at 9:59 AM, Mark Phippard wrote:

> 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/

Please contact me if you should have any questions.

Gavin 'Beau' Baumanis
Principal
The SpiderNet Web Design

E: gavinb_at_thespidernet.com
M: +61 -4 38 545 586
W: http://www.thespidernet.com

---------------------------------------------------------------------
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 07:55: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.