You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bob Jenkins <rj...@collab.net> on 2008/04/18 20:55:31 UTC
Obliterate and auditability
I see that this topic has once again surfaced thanks to Karl. And it is
a logical feature to consider. I wanted to provide my own perspective on
what I think Subversion's approach should be to this request and as a
result add what I believe to be a valuable additional requirement.
I realize that today the ability to permanently delete anything comes
from a manual manipulation of a Subversion dump file. That is a fairly
extraordinary effort to go through, but one that can be automated and
improved upon via something like what has been proposed. That said I'd
like to see the concept of auditability be a requirement in any
potential formal obliterate feature. In proposing that such be a
requirement I recognize that manual manipulation is still going to be
possible, but that's always possible for a version control when someone
has the right access and knowledge.
One of the key purposes for any version control tool is to provide the
historical record of what happened, to what, by whom, and what did they
say about it. The recording of that data is central to providing an
audit record as to what has happened historically to all the contents of
the repository. Many industries and individual companies are required to
be able to provide such audit data whenever it is requested. That calls
for an immutable system. On the other hand, there are distinct times
when something should not be retained. Most obvious are the situations
where proprietary or objectionable content is involved. That calls for
the ability to eliminate any record of that data. However, support for
the later use case compromises the credibility of the first use case.
Nothing can guarantee that the obliterate action is being taken only for
situations that fit the criteria listed above and therefore, potentially
important audit data can be removed as though it never existed.
That's the situation that almost all existing version control tools find
themselves in. I've long since found it funny to hear how auditable
ClearCase is when it has functionality to delete versions as well as
paths themselves. That doesn't promise true auditability. One can point
to process controls as the way to limit access to the functionality, but
they can't really guarantee how such functionality was used.
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.
Gosh I write long e-mails - sorry about that.
Regards,
Bob Jenkins
Practice Manager, Subversion Services
www.collab.net <http://www.collab.net/>
Office: 770.977.5508
Cell: 678.296.0491
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
I remember discussions about something like this from the Subversion
summit (now more than a year and a half ago...).
+1
Bob Jenkins wrote:
>
> I see that this topic has once again surfaced thanks to Karl. And it
> is a logical feature to consider. I wanted to provide my own
> perspective on what I think Subversion’s approach should be to this
> request and as a result add what I believe to be a valuable additional
> requirement.
>
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Gavin 'Beau' Baumanis <ga...@thespidernet.com>.
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 <br...@xbc.nu> wrote:
>> Karl Fogel wrote:
>>
>>> Branko Čibej <br...@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@thespidernet.com
M: +61 -4 38 545 586
W: http://www.thespidernet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Mark Phippard <ma...@gmail.com>.
On Sun, Apr 20, 2008 at 5:40 PM, Branko Čibej <br...@xbc.nu> wrote:
> Karl Fogel wrote:
>
> > Branko Čibej <br...@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/
Re: Obliterate and auditability
Posted by Peter Wemm <pe...@wemm.org>.
On Mon, Apr 21, 2008 at 4:17 PM, Garance A Drosihn <dr...@rpi.edu> wrote:
> At 10:10 AM -0400 4/21/08, John Peacock wrote:
>
> > C. Michael Pilato wrote:
> >
> > > I say that Subversion shouldn't bother with dropping revisions,
> > > should record obliterations as revision properties, and that's that.
> > >
> >
> > +1
> >
> >
> > > But I resonate with those who believe that auditability as a goal
> > > runs closer to the spirit of what a version control tool is than
> > > does the untraceable disposal of versioned data.
> > >
> >
> > <aol>me too!</aol>
> >
>
> +1 for me on these comments. And since I don't say much on this
> mailing list, let me note that I am a person who *does* want an
> official easy way to 'Obliterate' a previously-commited revision.
> But I don't think we need to obliterate the fact that the revision
> ever existed.
Likewise from me. We wouldn't care if the changeset shrank or became
empty. I don't care either way about logs mentioning it. If a log
didn't mention it, I'd probably edit svn:log to make an explicit note,
depending on the circumstances.
Obliterating the data is a separate issue versus hiding the history.
We (freebsd.org) need the former functionality. Doing a dump, edit,
restore is extremely unpleasant, but would get us by in a pinch.
Making this less painful would be a fantastic improvement and would be
well worth having as an available tool - hopefully one never used.
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Garance A Drosihn <dr...@rpi.edu>.
At 10:10 AM -0400 4/21/08, John Peacock wrote:
>C. Michael Pilato wrote:
>>I say that Subversion shouldn't bother with dropping revisions,
>>should record obliterations as revision properties, and that's that.
>
>+1
>
>>But I resonate with those who believe that auditability as a goal
>>runs closer to the spirit of what a version control tool is than
>>does the untraceable disposal of versioned data.
>
><aol>me too!</aol>
+1 for me on these comments. And since I don't say much on this
mailing list, let me note that I am a person who *does* want an
official easy way to 'Obliterate' a previously-commited revision.
But I don't think we need to obliterate the fact that the revision
ever existed.
When it comes to making sure 'Obliterate' is not leaving behind any
sensitive information, I'd be happy enough with some vague note of
what the revision did. "Revision #1313 changed files in directory
<x>, but those changes have been completely removed as of <date>",
where <x> is the name of some directory which existed before that
revision was made. Ie, you wouldn't record the name of any files
which were changed, or any directories which had been added by the
revision that you are now obliterating.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by John Peacock <jo...@havurah-software.org>.
C. Michael Pilato wrote:
> I say that Subversion shouldn't bother with dropping revisions,
> should record obliterations as revision properties, and that's that.
+1
> But I resonate with those who believe that auditability as a goal
> runs closer to the spirit of what a version control tool is than does
> the untraceable disposal of versioned data.
<aol>me too!</aol>
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> I agree with this, but didn't appeal to this argument to support my
> opinions. (I'll take "By the way" to mean you were just using the
> mail you were already writing to state a general belief to all those
> following the thread.)
Yes, there I was responding to specific comments others had made in the
thread, not to you (should have made that clear).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> The answer "people can use svndumpfilter" applies to most obliterate
> cases. But my point is that if users are resorting to svndumpfilter to
> do something, that must mean *they want to do it* -- so why should we
> make them jump through hoops?
I think you know the possible answers to this question already, but for the
sake of openness, I'll note a couple. We (and indeed any group of software
developers) make people jump through hoops any time it is believed that:
* the cost of implementation and maintenance of some feature exceeds its
benefit ("cost" here is vague -- misaligning priorities incurs cost;
overcoming design shortcomings incurs cost; overcoming basic shortages of
time/people/skills incurs cost; ...)
* the feature is not aligned with the purpose and vision of the software
With some time I could probably make the case that this latter reason is
actually just a flavor of the first.
Now, I don't claim to know the current cost/benefit balance for this feature
as a whole -- that's part of what we're exploring here.
> Of course auditability should be the default, and I'm not claiming that
> removal of revisions is the common case (feedback indicates it is not).
> But it's easy to implement along with everything else, so why not do it?
> If we're telling people to use svndumpfilter, for something we could
> easily give them in Subversion itself, that's silly: we should just give
> it to them outright.
(As you well know, initial implementation isn't the only cost.) But is the
initial implementation even "easy"?
> By the way, the argument that we shouldn't help users do illegal things
> doesn't really hold up. We could just as easily make up an example
> about an admin trying frantically to eliminate all evidence of a data
> event before some repressive regime's police show up to seize the
> servers and put everyone in jail. You really can't know in advance
> whether you're going to morally approve of the uses of your software
> (hence the clause about "no discrimination against fields of endeavor"
> in the Open Source Definition and the Debian Free Software Guidelines).
I agree with this, but didn't appeal to this argument to support my
opinions. (I'll take "By the way" to mean you were just using the mail you
were already writing to state a general belief to all those following the
thread.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Karl's obliterate-via-svnsync plan (in that he was the first to send
> dev-list email about this already-considered idea)
Whups, sorry; if I'd remembered prior discussions about this I would
have just pointed to them (or at least credited someone). I often
remember ideas without remembering their provenance -- this appears to
be one of those cases.
> seems like a good
> one; a fine way to finally answer this feature request which has been
> haunting us for years. I am in favor of seeing this feature happen,
> so I don't want to come across as an anti-obliterater. But I resonate
> with those who believe that auditability as a goal runs closer to the
> spirit of what a version control tool is than does the untraceable
> disposal of versioned data.
Huh. The "Make It Never Have Happened" use case has been part of our
obliterate discussions since the feature was first proposed, mentioned
in http://subversion.tigris.org/issues/show_bug.cgi?id=516#desc1 even.
The answer "people can use svndumpfilter" applies to most obliterate
cases. But my point is that if users are resorting to svndumpfilter to
do something, that must mean *they want to do it* -- so why should we
make them jump through hoops?
Of course auditability should be the default, and I'm not claiming that
removal of revisions is the common case (feedback indicates it is not).
But it's easy to implement along with everything else, so why not do it?
If we're telling people to use svndumpfilter, for something we could
easily give them in Subversion itself, that's silly: we should just give
it to them outright.
By the way, the argument that we shouldn't help users do illegal things
doesn't really hold up. We could just as easily make up an example
about an admin trying frantically to eliminate all evidence of a data
event before some repressive regime's police show up to seize the
servers and put everyone in jail. You really can't know in advance
whether you're going to morally approve of the uses of your software
(hence the clause about "no discrimination against fields of endeavor"
in the Open Source Definition and the Debian Free Software Guidelines).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej wrote:
> Miha Vitorovic wrote:
>> Branko Čibej <br...@xbc.nu> wrote on 21.04.2008 08:13:42:
>>
>>
>>> 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.
>>>
>>
>> This may be a stupid question, but doesn't some fiddling with the dump
>> file achieve exactly that? So even though there is no "svn obliterate"
>> command, putting it in would not make you any more responsible for
>> destroying potential evidence than you (the project) already are.
>>
>
> I'd prefer not to be hung for a naïve-seeming sheep.
Actually, I think this point about there already existing a way to
accomplish breadcrumb-free obliteration is a meaningful one, because it
relinquishes us as developers of the obligation to support all such
use-cases as first-class features. I say that Subversion shouldn't bother
with dropping revisions, should record obliterations as revision properties,
and that's that. If folks want to modify those revprops later to mask the
obliteration, a mechanism already exists for doing us. If they further wish
to drop the now-empty revisions, mechanisms (albeit not-so-automated ones)
exist for doing that, too. Let those who wish to rewrite history do so at
their cost, not ours.
Karl's obliterate-via-svnsync plan (in that he was the first to send
dev-list email about this already-considered idea) seems like a good one; a
fine way to finally answer this feature request which has been haunting us
for years. I am in favor of seeing this feature happen, so I don't want to
come across as an anti-obliterater. But I resonate with those who believe
that auditability as a goal runs closer to the spirit of what a version
control tool is than does the untraceable disposal of versioned data.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Miha Vitorovic wrote:
> Branko Čibej <br...@xbc.nu> wrote on 21.04.2008 08:13:42:
>
>
>> 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.
>>
>
> This may be a stupid question, but doesn't some fiddling with the dump
> file achieve exactly that? So even though there is no "svn obliterate"
> command, putting it in would not make you any more responsible for
> destroying potential evidence than you (the project) already are.
>
I'd prefer not to be hung for a naïve-seeming sheep.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Miha Vitorovic <mv...@nil.si>.
Branko Čibej <br...@xbc.nu> wrote on 21.04.2008 08:13:42:
> 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.
This may be a stupid question, but doesn't some fiddling with the dump
file achieve exactly that? So even though there is no "svn obliterate"
command, putting it in would not make you any more responsible for
destroying potential evidence than you (the project) already are.
Br,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> Indeed. I'm surprised that you think changing log messages is an
> incidental etcetera. Maybe so, in some contexts. One could say the
> same about, e.g., svn:author.
I overstated my case, out of a desire to counter a different argument.
I don't think any of our revprops are incidental, and strongly wish them
to be versioned in some way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>
>> kmradke@rockwellcollins.com wrote:
>>
>>> On a side note, it has always bothered me that changing revision
>>> properties leaves no audit history trace... Does this bother
>>> anyone else?
>>>
>> Yes. :)
>>
>
> No :-).
>
> Or at least, it doesn't bother me as much as it bothers some people,
> though I'd be happy to see audit trails / rewindability for log
> messages.
>
> There's a myth going around that our unaudited log messages mean
> Subversion doesn't have the "time safe" property. But Subversion is
> time-safe. The question with time safety is always "What things are in
> scope and what things are out of scope?"
>
Indeed. I'm surprised that you think changing log messages is an
incidental etcetera. Maybe so, in some contexts. One could say the same
about, e.g., svn:author.
But using our wrong-headed model as an argument for its perpetuation
isn't going to help.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by km...@rockwellcollins.com.
Karl Fogel <kf...@red-bean.com> wrote on 04/21/2008 10:55:13 AM:
> Branko Čibej <br...@xbc.nu> writes:
> > kmradke@rockwellcollins.com wrote:
> >> On a side note, it has always bothered me that changing revision
> >> properties leaves no audit history trace... Does this bother
> >> anyone else?
> >
> > Yes. :)
>
> No :-).
>
> Or at least, it doesn't bother me as much as it bothers some people,
> though I'd be happy to see audit trails / rewindability for log
> messages.
>
> There's a myth going around that our unaudited log messages mean
> Subversion doesn't have the "time safe" property. But Subversion is
> time-safe. The question with time safety is always "What things are in
> scope and what things are out of scope?"
So you basically are saying the repo is "time safe" with respect to
file contents, which is a valid point. Revprops typically don't
affect the contents, they are just information. (And by default
revprop mods are "off", so it is by user/admin choice they can
be modified)
> You could implement a repository just like Subversion's, except without
> log messages, and instead people could just stick post-it notes to
> revisions. Sometimes they might remove a post-it note and replace it
> with a new one. We couldn't prevent that -- after all, a revision is a
> label, and if people want to write other documents that happen to
> *refer* to those labels, well... It's like trying to stop someone from
> linking to you on the Web: a URL is just a string other people may use
> in their own documents.
>
> All we've done with log messages and other revprops is make a very
> convenient way to attach post-it notes to our revisions.
>
> I'm answering a question other than the one you asked, of course. It
> might be useful if we started versioning those post-it notes, and I'm
> definitely for it. But I do want to dispel the myth that it's related
> to time safety (which you didn't bring up), and this seemed as good a
> place as any.
I'm fairly happy with the current functionality. It "bothers" me
mainly because I sometimes forget when/why some values were changed,
so having a history/audit log would be helpful. In fact, I hadn't
even though about "time safety"...
And in reality, it would be trivial to write a post-revprop-change
hook to append revprop change history to a file I could reference later.
(One wonders why I hadn't thought of this sooner...)
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> kmradke@rockwellcollins.com wrote:
>> On a side note, it has always bothered me that changing revision
>> properties leaves no audit history trace... Does this bother
>> anyone else?
>
> Yes. :)
No :-).
Or at least, it doesn't bother me as much as it bothers some people,
though I'd be happy to see audit trails / rewindability for log
messages.
There's a myth going around that our unaudited log messages mean
Subversion doesn't have the "time safe" property. But Subversion is
time-safe. The question with time safety is always "What things are in
scope and what things are out of scope?"
You could implement a repository just like Subversion's, except without
log messages, and instead people could just stick post-it notes to
revisions. Sometimes they might remove a post-it note and replace it
with a new one. We couldn't prevent that -- after all, a revision is a
label, and if people want to write other documents that happen to
*refer* to those labels, well... It's like trying to stop someone from
linking to you on the Web: a URL is just a string other people may use
in their own documents.
All we've done with log messages and other revprops is make a very
convenient way to attach post-it notes to our revisions.
I'm answering a question other than the one you asked, of course. It
might be useful if we started versioning those post-it notes, and I'm
definitely for it. But I do want to dispel the myth that it's related
to time safety (which you didn't bring up), and this seemed as good a
place as any.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
kmradke@rockwellcollins.com wrote:
> On a side note, it has always bothered me that changing revision
> properties leaves no audit history trace... Does this bother
> anyone else?
>
Yes. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by km...@rockwellcollins.com.
Branko Čibej <br...@xbc.nu> wrote on 04/21/2008 01:13:42 AM:
> Karl Fogel wrote:
> > Branko Čibej <br...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, 21 Apr 2008 at 08:46 +0200:
>
>> Karl Fogel wrote:
>>
>>> Branko Čibej <br...@xbc.nu> writes:
>>>
>>>
>>>> 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.
>>>>
>>>>
>>> It's the legal case, I think.
>>>
>>> "No, Your Honor, we never made such a change on the date in question."
>>> "Oh, then why does your history have an empty revision on that date?"
>>>
>>>
>> And that's exactly what Dan Berlin said we shouldn't do, at the summit. There
>> was some talk about triple damages and suchlike. I don't think we should be in
>> the business of helping people break the law, eh? We might even be held liable
>> because of posts like this one.
>>
>>
>
> Yes, some people may use a new feature to break the law. Why is this
> an argument against that feature?
>
It's not. It's just not an argument /for/ the feature. I haven't heard a
good one yet.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Branko Čibej wrote on Mon, 21 Apr 2008 at 08:46 +0200:
> Karl Fogel wrote:
> > Branko Čibej <br...@xbc.nu> writes:
> >
> > > 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.
> > >
> >
> > It's the legal case, I think.
> >
> > "No, Your Honor, we never made such a change on the date in question."
> > "Oh, then why does your history have an empty revision on that date?"
> >
>
> And that's exactly what Dan Berlin said we shouldn't do, at the summit. There
> was some talk about triple damages and suchlike. I don't think we should be in
> the business of helping people break the law, eh? We might even be held liable
> because of posts like this one.
>
Yes, some people may use a new feature to break the law. Why is this
an argument against that feature?
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> We might even be held liable because of posts like this one.
Unless a lawyer actually told you that (which seems highly unlikely),
I've got to file this one in the FUD bucket :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@xbc.nu> writes:
>
>> 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.
>>
>
> It's the legal case, I think.
>
> "No, Your Honor, we never made such a change on the date in question."
> "Oh, then why does your history have an empty revision on that date?"
>
And that's exactly what Dan Berlin said we shouldn't do, at the summit.
There was some talk about triple damages and suchlike. I don't think we
should be in the business of helping people break the law, eh? We might
even be held liable because of posts like this one.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@xbc.nu> writes:
> 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.
It's the legal case, I think.
"No, Your Honor, we never made such a change on the date in question."
"Oh, then why does your history have an empty revision on that date?"
Indeed, the mere presence of empty revisions is a sign that something
odd has happened, attracting attention precisely where the repository
owner may not want attention.
Now, we could say that it's not Subversion's business to help its users
lie. But we don't typically apply that standard to use cases -- we just
assume our users have good reasons for doing whatever it is they want to
do. We question intent only when we think there might be a technically
better way to achieve the same goal; if we were to question intent here,
it would be for different reasons.
> Heh. Just don't forget that you can fit more Vibrio cholerae into a
> thimble than worms in any reasonably-sized can.
http://www.worldslargestthings.com/california/fruitcocktail.htm
(You might still be right, though.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@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.
> I doubt the auditability bikeshed is going to be a design hog here.
> There are various reasonable ways to do it -- if we're implementing
> obliterate, then we'll pick one of those ways. Hanging things on
> revision numbers seems fine to me, and so far the can of worms looks
> more like a thimble of bacilli :-).
>
Heh. Just don't forget that you can fit more Vibrio cholerae into a
thimble than worms in any reasonably-sized can.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by "C. Michael Pilato" <cm...@collab.net>.
C. Michael Pilato wrote:
> Karl Fogel wrote:
>> 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!
>
> [I've not crawled the issue tracker for the arguments supporting this,
> so if the answers lie there, feel free to refer me away.]
>
> Why, exactly, must we "definitely" support this use-case?
(Sorry for the double noise ... I see the thread continued on to answer this.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Obliterate and auditability
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> 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!
[I've not crawled the issue tracker for the arguments supporting this, so if
the answers lie there, feel free to refer me away.]
Why, exactly, must we "definitely" support this use-case?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Greg Hudson <gh...@MIT.EDU> writes:
> I am not aware of sound scenarios supporting "remove a revision without
> a trace." I don't mind if Subversion allows users to do that (it's not
> very hard to do that to the most recent revision by hand, at least in
> FSFS), but such a feature travels well beyond the scope we had strong
> support for in the first place.
I hadn't thought it was scope creep -- my impression was that people
were asking for it all along. That's the only reason I'm flogging it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2008-04-21 at 01:52 -0400, Karl Fogel wrote:
> We will definitely want to support the use case where the revision
> number itself has to go away.
I'm going to echo CMike's question. This seems like scope creep. There
are some very sound scenarios supporting obliterate support in the first
place, like someone accidentally committing a pre-release copy of Star
Wars episode VII to the Subversion repository. In that case, copyright
infringement concerns trump historical accuracy concerns.
I am not aware of sound scenarios supporting "remove a revision without
a trace." I don't mind if Subversion allows users to do that (it's not
very hard to do that to the most recent revision by hand, at least in
FSFS), but such a feature travels well beyond the scope we had strong
support for in the first place.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@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!
I doubt the auditability bikeshed is going to be a design hog here.
There are various reasonable ways to do it -- if we're implementing
obliterate, then we'll pick one of those ways. Hanging things on
revision numbers seems fine to me, and so far the can of worms looks
more like a thimble of bacilli :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> Branko Čibej <br...@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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
Branko Čibej <br...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
> "Bob Jenkins" <rj...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Obliterate and auditability
Posted by Karl Fogel <kf...@red-bean.com>.
"Bob Jenkins" <rj...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org