[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Another request for obliterate...

From: Denny Page <denny_at_cococafe.com>
Date: 2005-04-18 20:14:10 CEST

I am assuming the obliterate would be an administrator command, not
available to end users. As has been noted, non-administrative users
should not have access to commands that can cause irreparable damage to
the repository. This is a policy that I agree with. However, I also
believe that administrators need the ability to correct "problems" with
the repository.

The problem that concerns me the most is the check in of "compromising"
materials such as access codes, personal information, copyrighted
material (that we don't have rights to), porn, etc.

The other problem is "junk" that shouldn't have gone into the repository
in the first place. Just because some configuration management happy
user successfully checks in a 5GB database file, doesn't mean that I as
an administrator shouldn't be able to fix it.


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

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:17:30 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.