[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-07-21 07:42:43 CEST

Talden <talden@gmail.com> writes:
> 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.

As far as I know, all the developers agree that the feature is
desirable. No one has funded the work, and no one has volunteered to
take it on either (starting with the design work, which should be
considered part of the process). Therefore it hasn't happened.

I feel like when someone says this, others somehow hear it as the
developers saying "Talk to the hand!" or "Patches welcome!".

But it's not like that. We're merely pointing out that, for whatever
reason, no one has taken this on. We're not against the feature --
we're in favor of it. The way it will happen is when someone takes
charge and starts a serious requirements and design discussion on
dev@, and then follows through with patches. It doesn't have to be an
existing developer, it can be someone new.

(There have been some offers to fund obliterate; my recollection is
that they just weren't enough money to do the job, but I could be

Running those discussions is hard. It requires a lot of patience and
a talent for organizing and distilling complex feedback. But it *is*
doable. We did it for locking, for example; see the archives for how
that process went.

Again, we want obliterate, at a general level. We just need a better
definition of the feature, and that takes work.


Subversion support & consulting  <>  http://producingoss.com/consulting.html
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 21 07:41:48 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.