Re: Re: Elliotte Rusty Harold gets it wrong

> > The arguments for security and pruning notwithstanding, the
> > *idea* of an
> > obliterate seems, well, incongruous to the very nature of a
> > versioning,
> > history-preserving repository.

> I think this could be addressed by large warnings, rather than not
> having the option at all!

Or, more to the point, since the facility has already been provided,
albeit inconveniently, via dump, dump-filter and load let's at least
make it more usable.

Making it hard doesn't really resolve data-loss concerns - besides, if
the policy is that Subversion should never, ever lose content then it
should probably at least:

- Not provide any official means to tamper with dump-files.
- Consider securing dumps with checksums and providing only binary
dumps containing diffs as this complicates any efforts to tamper with
content.

But, since that isn't the case, if we're only adding an 'svnadmin
obliterate' that avoids the often excessive costs in space and time
for complete dumps, filtering and reloads but has the same 'large,
large asterisk' of the existing mechanism then all we're doing is
merely improving existing UI not adding new functionality.

Improving the functionality would be nice too of course, but let's not
get hasty, it's not like this issue has been around for long... or
raised by many users...

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org