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
Received on Mon Apr 18 19:57:45 2005