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.
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.
--
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2418415
Received on 2009-11-16 11:17:52 CET