On 10-Oct-07, at 7:09 PM, Talden wrote:
>>> 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...
The pros and cons have been exhaustively pre-hashed. The topic
demands simple citations from now on.
--Toby
>
> --
> Talden
>
> ---------------------------------------------------------------------
> 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 Thu Oct 11 02:58:48 2007