Julian Foad wrote:
> Philip Martin wrote:
>> I see you have added an RA obliterate_path_rev function. I realise
>> it's just a preliminary but does it represent an intention to pass the
>> obliteration set over RA rather than driving an editor? An editor
>> drive would seem to be better simply because it again looks more like
>> a commit.
> I hadn't really thought of an editor drive. At SubConf, Alex Kitaev
> suggested an idea about using a commit as some part of the design; I
> thought he was talking more about modelling the user interface
> experience on how a commit is done: set up local mods first and then
> commit it.
> That does have advantages. It's more general. It's already implemented
> over all RA layers. The txn-modifying code is already implemented,
> though I would need a specialized version of that. I don't see a problem
> with restricting the operations that are allowed, to prevent arbitrary
> text mods, for example.
> Down-sides? The additional flexibility, even with restrictions, feels
> like it could be more complex to handle than a simple "delete these
> paths" (which is, within a single revision, the most general form of
> what I have now). It doesn't address the need to obliterate a path over
> a large range of revisions, so that would have to be added on in some
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.
Received on 2009-11-12 18:04:10 CET