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

Re: Obliterate questions

From: Branko Cibej <brane_at_xbc.nu>
Date: Mon, 16 Nov 2009 13:40:16 +0100

Philip Martin wrote:
> Branko Cibej <brane_at_xbc.nu> writes:
>> On the face of it, an editor drive seems like a good fit for
>> obliteration. But you end up with so many restrictions -- you basically
>> only allow "delete path" edits, and even those behave differently from
>> normal commits -- that you'll likely end up going down entirely
>> different code paths. My next concern is that a bug in handling the
>> restrictions could allow all sorts of changes to creep in ... so I'd
>> rather have the obliterate path completely separate fromthe commit path.
>> I don't think we really want to make obliterate "flexible" and
>> "extensible" for adding more features in the future. You have a well
>> defined, well constrained design; don't go messing up existing commit
>> code for the sake of flexibiliy where you don't even conceivably need it.
> The current proposal is to replace an existing revision with a new
> version of the revision that contains some new nodes (with new
> node-revision ids?). Once we get that working for obliterate it has
> the potential to allow more complicated rewriting. It seems odd to
> design such a powerful backend and then limit it so severely by the RA
> interface. One conceivable flexibility would be to allow obliterate
> (or "rewrite") to modify a file text rather than obliterate it.

Yes -- and that way lies insanity. Even obliterate, as specified now,
walks on the brink of "proper version control". Rewriting history in
more subtle ways is much, much worse -- and I can't really imagine a
sensible use case for it.

Just because we /can/ support flexible modifications of history doesn't
mean we should contemplate them. This is the "I have a hammer,
everything is a nail" sort of approach.

> It's not a decision we have to make now. We can continue with the
> existing RA interface proposal until we see how well the backend
> implementation works.

It will work well; there's no doubt that the design is sane.

-- Brane

Received on 2009-11-16 13:40:31 CET

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