Philip Martin wrote:
> I've been reading the obliterate stuff. I have lots of questions but
> I'll start with a few:
Hurrah! Thank you.
> The initial outline for the obliterate txn for PATH_at_R is a variation
> on a standard commit txn. Your plan has milestones for extension
> first to multiple revisions and then multiple paths at multiple
> revisions. Why that order? To me it would appear easier to extend
> first to multiple paths at a single revision since that is again a
> variation on a standard commit txn. I suppose users want multiple
> revisions more than they want multiple paths?
Yes, exactly. No deeper reason than that. (I should add a note that that
is not an important ordering.)
> Given the similarities between commit and obliterate should obliterate
> get all three (start-, pre-, post-) hooks? Should the pre- hook get
> the txn ID as a parameter rather than the obliterate set on stdin?
Hmm, that sounds a very good idea. Thanks. Consistency is a Good Thing.
> Are you planning to obliterate multiple revisions in a single txn?
That's where I need some seriously hard thinking. Yes, I would like to
obliterate multiple revisions in a single txn, because otherwise
obliterating a half-a-million-rev range would be very slow.
The only idea I have as yet is that the node-revs for the history of one
object in such a range will in practice often consist of relatively few
history segments, where the same node content exists for say 50000 revs
and then is changed. I hope we can use that fact to help speed up
(massively) the obliteration of such a range by doing it one segment at
a time, compared with doing it one rev at a time. I don't know yet how
to wrap such a segment-deletion in some kind of multi-rev transaction to
isolate it from concurrent readers and writers.
> 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.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417002
Received on 2009-11-12 13:20:02 CET