I attended the recent perforce user conference where I had the
opportunity to discuss subversion with a number of folks including
several who administer both subversion and perforce. The lack of an
obliterate command in subversion came up more than as an issue,
always associated with the management of large repositories where
the administrator may be called upon to 'clean up' after users in
exactly the manner that Denny Page describes.
At the conference I also learned that some people use their
repositories in ways that are unexpected (at least by me). One
prominent vendor known for virtualizing x86 systems in software
stores their entire development toolchain in their repository,
including executables, scripts, and shared libraries. As old
products are EOL'd or whatever, it may be considered desireable
for these modules to be culled as they can easily reach many
gigabytes in size.
Among the more common critiques of the perforce version of
obliterate was the difficulty in locking the command for use
only by administrative user. Also, it is necessarily slow, which
perhaps should be considered a feature.
FWIW, I am for an svn obliterate as part of svnadmin.
D
On Mon, Apr 18, 2005 at 11:14:10AM -0700, Denny Page wrote:
> 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.
>
> Denny
>
>
> >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
---------------------------------------------------------------------
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:54:54 2005