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

Re: Proposal for sponsored development of "Obliterate"

From: Jack Repenning <jrepenning_at_collab.net>
Date: Mon, 27 Jul 2009 10:51:07 -0700

On Jul 19, 2009, at 11:26 AM, Julian Foad wrote:

> I now have a fairly detailed proposal for developing "Obliterate".
> (Attached.)

In your Intro, you call out the two distinct forms I've know of for
Obliterate, then add what you call a "notable case of the former":
removal of certain deltas of a file, leaving prior and subsequent
history intact. I think this case deserves visibility as yet a third
case, rather than being treated as a subcase of either of the others.
So we would have these Obliterate cases:

1. Utterly removing all traces that a certain file or collection of
files ever existed in the repository. (My restatement of your first

2. Removing obsolete data from space motives. (Your second.)

3. Selective excision of history from file or files whose prior and
subsequent history remains intact. (Your "notable case.")

Not the least of my reasons for wanting to call this a separate item
is this: at CollabNet, we've had many customers asking for #1 and #2,
but to the best of my knowledge not a single word has ever been spoken
in favor of #3.

Given the frequent and emphatic demands for numbers 1 and 2 we've had,
I am candidly baffled why CollabNet has not managed to fund this work
to date (and I hope you'll include us in your list of people to whom
to submit the proposal). But I would be surprised if CollabNet were
willing to extend any deadlines or provide any incremental funding for
the third form.

Similarly, the commercial input we've had on this feature is almost
totally unconcerned about the impact on working copies. While no doubt
everyone would agree that preserving WC health where possible is good,
rather than bad, the people who have offered us money for anything in
this domain were perfectly willing to sacrifice this in order to get
the primary, server-side benefits.

Going back to my restatement of your first case: one change I made in
the wording was to remove the word "accidentally." There's some point
to this: the thing added was often no accident, but rather further
review, or changing circumstances, compel the removal. A real-world
example that may be familiar to at least some readers: in the Eclipse
community, they have fairly detailed constraints on the licensing of
externally sourced modules added to the Eclipse site. But because
review is expensive, they also have a procedure called something like
"Deferred Intellectual Property," where an Eclipse project is allowed
to add previously un-reviewed stuff speculatively, in parallel with
launching the license review. If the review should turn out badly,
then the component must be removed--utterly removed: the lawyers have
determined that the mere presence of this module in the build tree is
a license violation. They're not concerned with preserving working
copy health for any working copy that includes the banned module: any
such working copy is a liability; if anything, it *should* begin
failing. They're not concerned with excising a nibble of history, they
want the whole dang thing gone, as if it had never been. And it may
well be that quite a number of development and interim builds have
been done, quite a number of dependent changes have been made, with
the now-banned module in place: it is, if anything, *desirable* that
such builds now become un-buildable, such changes fail to compile, and
whatever work it takes now be performed to replace or do without the
now-banned module. I removed "accidentally" in order to open the door
to this possibility of nontrivial amounts of accumulated history, and
nontrivial history breakage.

You asked:

> Do you think it's OK to leave time and money estimates till after
> someone shows an interest?

It's perfectly reasonable to leave out time and money from the
proposal you provide here, since it doesn't even commit itself to what
will actually be done! ;-) But I would think anyone considering
sponsorship would want to know that, and would certainly need a cost
write-up before committing. I dunno, though, how you best dance your
way into something more concrete (cf. "baffled," above).

Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
twitter: http://twitter.com/jrep

Received on 2009-07-27 19:51:37 CEST

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