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
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418478
Received on 2009-11-16 13:40:31 CET