Re: the obliterate discussion - why dumpfiltering is no valid workaround

I'm not going to gesticulate on why the feature is needed - I think
there have been a number of well presented scenarios in which an admin
would be forced into a painful and possibly impractical
dump/filter/load scenario. EG

- Legal or Confidentiality obligations.
- Repository size (a real concern for backups and syncing)

I would like to comment on some of the arguments against the feature
and comment on the barriers to getting the feature implemented.

First I'd like to try and eliminate a few of persisting
counter-arguments against an admin-only Obliterate feature...

1. Subversion is supposed to keep history, removing it is like
throwing away an audit trail.

We already are able to do a dump/load. This mechanism has most of the
desired effect, is currently supported and is promoted as the current
solution to the feature request.

Adding an admin-only equivalent does not compromise the system any
more than the existing dump/filter/load functionality. Providing a
faster, simpler workflow for the same effect is nothing more than a
usability improvement.

2. We don't want to make it too easy, Subversion is supposed to keep everything.

You are not my mother. Absolutely this feature needs to be
admin-only. Absolutely, documentation needs to spell out the effects
with appropriate warnings.

Admins, by their nature need to understand the importance of their
actions because there are many, many ways they can cause data-loss.
Making the job harder and more complex for admins INCREASES the risk
of data-loss as they are required to correctly perform several
additional steps over a larger length of time (a very similar issue
exists with merging and is why merge-tracking is so important).

Arguing that poor usability is a form of data-protection is much the
same as arguing that obfuscation is a real form of security.

3. No one has provided the development effort or funding for this
issue to be solved so it can't be important.

Given the number of requests for this feature it's obviously highly
desirable. A lack of progress does not truly rationalise the value of
the feature. We do not realistically know much many users require it,
how much the work-around is costing them or how much it's lack might
be contributing to users moving to other systems.

Many users do not have the skill-base to implement the necessary
changes or even design the solution. Other users are not in a
position to fund development either because they are not able to
secure budget for such development or because they are non-profit
organisations.

In this instance progress has halted due to an unwillingness to stage
the solution by first allowing introduction of a simpler/faster
solution to a dump/filter/load followed later by a more comprehensive
solution that maintains support for existing working copies and synced
mirrors.

(I've also observed a tendency of those who do not need a feature to
contest its addition - absolutely we don't want one non-critical
feature to complicate the usage of another, but if the features do not
affect each-other then there should be a barrier to growth of
functionality)

I'd argue here that users that are not interested in the feature
should still care. Broader capability means a broader audience. The
larger the Subversion user-base, the larger the number of contributors
(in effort or funds). We need to keep the adoption rate high and
combat the bleed rate - Subversion needs to be a low-risk proposition
that is seen as capable, stable, well-maintained and constantly
improving. Every single rebuttal of a feature request needs to be
well-founded - refusing feature requests with shaky arguments only
increases the perceived risk of adopting Subversion.

Okay. So why hasn't the issue progressed?

The most visible reason seems to be that the simple solution
(literally a more efficient implementation of the effects of
dump/filter/load) is seen as a non-solution - after-all, it's going to
break synced mirrors and working copies.

Absolutely. So does a dump/filter/load. If a simple solution is able
to provide the same side-effect as dump/load whilst dramatically
simplifying admin effort and reducing downtime then it is unarguably
an improvement to an existing, albeit incomplete solution to the
use-case.

We certainly shouldn't consider such a simple solution as the end of
the story - many existing users will not be able to justify the use of
this simple solution (though those admins should know then not to use
it of course). Full rebuilds of synced mirrors and new working copies
for users will be unacceptably expensive in some situations.

Of course this last argument that getting new working copies and
rebuilding mirrors is too expensive is precisely the argument as to
why dump/filter/load is unusable for others.

So can we all, at last, focus on assessing the requirements of the
feature (I expect log message appends and replacements are candidates
as well as an includes/excludes file).

It'd be great after so many years of requests to get past this stage
and actually move this to dev where people can start devising the
necessary updates to (what I assume is) the FS layer to support
filtering out paths of existing revs and evaluating the approach and
effort to implement this in the two supported FS implementations.

I await your comments...

...hopefully I can hear them from my subterranean, asbestos-lined
bomb-shelter that I'll prudently retreat to immediately following this
post.

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