Ok, after thinking over the arguments presented here, I can see there
being a case for this feature. Given that, let's think about *how* such
a feature needs to be put in place:
First, svnadmin *only* -- I think we all agree with this to avoid the
"Sorry, honey, I trashed the repository" syndrome.
Now, let's think about "svnadmin obliterate foo.c". How must this work?
Does it always start at the head revision? Yes, if it's a true
obliterate, but I cannot assume that foo.c exists in the head, since
someone might have done an "svn rm" on it (this is quite common, since
the first thing a user does after a "wrong" commit is hide their mistake
:)). So I certainly need both an URL and a revision to specify the
"two-dimensional" point in the repo to obliterate.
OK, so which "foo.c" revisions do I obliterate? Clearly I can work
backwards through time, killing all the foo.c revisions before the
specified revision. Should I also work "forwards", so if I obliterate
foo.c rev 10, should I also delete rev 11, 12 etc? I think the answer is
"yes", since (a) that's what "obliterate" means, (b) what exactly do
these orphanedrevisions mean anyway and (c) it's very hard to preserve
these given the structure of repos (particularly fsfs).
So, we assume that foo.c gets deleted forward from a revision to its own
"head" revision, and backwards toward it's first "svn add". What about
renames? Should I trace backwards across renames? Scenario: Mr. "Nasty"
is about to be fired and knows it. He renames a project-critical file to
"oops.c", and commits. Then he tells his admin: "Hey, I just commited
oops.c by mistake!". No problem, says the admin, and obliterates it. BUT
obliterate tracks the rename, and actually kills the project critical
file! Remember, it's "obliterate", so there is no going back: *none*
(except for backups).
What about branches? If I'm going "up" the tree (from older revs to
new), do I follow all the branches, obliterating all branches copies? If
not, how can I make sense of the fact that a file will exist in a branch
but has no prior existence? It will seem to appear in the branch from
nowhere. Branches are even worse going backwards through revisions. What
do I do at a branch point? Again, I cannot ignore it, because if I do
I'll create orphans. So I have to follow "up" the branch as well.
Essentially, to ensure a coherent repo, I'm forced to trace from one
revision of foo.c to all others both up and down the branch tree, and
delete them all.
Basically, what obliterate has to do is kill *all* revisions of foo.c,
regardless of renames, throughout the entire branch tree. Note that this
will include tags also, which means that tags are no longer invariant.
Now *that* I find scary -- which is what puts me off having this feature.
--Tim
Scott Palmer wrote:
>
> On Apr 18, 2005, at 1:27 PM, Tim Hill wrote:
>
>> OK, I agree that production disk costs are more significant. However,
>> I think the cost of an obliterate command would be higher. Why?
>> Experience! I've worked on large projects where the SCC system did
>> have such a feature -- and what a mess it caused. First, people would
>> not think before a check-in ("I can always obliterate it later"), so
>> in fact *more* junk was checked in than ever (now start thinking disk
>> costs). Second, every single obliterate caused horrible shock-waves.
>> I would get people to swear on their mother's graves that the
>> obliterate would have no side-effects and it *always* did. Builds
>> broke. Diffs went into the left field. Yuck.
>>
>> Now, this was a large project, pretty well managed, and not in any
>> way atypical.
>>
>
> I just thought I would chime in and say that previously when using
> Visual Source Safe, which has an 'obliterate' equivalent, I used it
> several times and *never* had any issues with it.
>
> There are simply times when you want to be able to clean house. There
> have been several arguments for 'obliterate' which have yet to be
> refuted:
> - mistakes. e.g. accidentally checked in a bunch of .o files (with
> debug info, just to make them big:) ) from a WC.
> - accidentally checked in sensitive information, e.g. passwords,
> somebody else's intellectual property
> - culling dead projects from the repo.
>
> The 'sensitive info' thing has nothing to do with disk space, so
> arguments based on that don't count. And as many have pointed out,
> there is much more to the issue than to say "disk space is cheap".
> There are also factors such as how long it takes to backup, and the
> cost associated with that maintenance.
>
> To me it just makes sense to have obliterate. Not having it is like
> never being able to delete files on your HD. You could try to make
> an argument that that is a good thing, but for practical purposes it's
> just silly.
>
> Also, the point above that people would not think before checking
> stuff in is a poor excuse. For one, it has been proposed that only
> the admin be allowed to obliterate. And while I generally don't like
> this line of reasoning, it could be said that you have 'bigger
> problems' if your developers are that careless. (Same could be said
> for mistakes such as checking in passwords, but reality is that
> mistakes happen.)
>
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 18 20:30:50 2005