[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: Thu, 12 Nov 2009 18:03:54 +0100

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
> way.

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.

-- Brane

Received on 2009-11-12 18:04:10 CET

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