[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: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 12 Nov 2009 12:19:34 +0000

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

- Julian

Received on 2009-11-12 13:20:02 CET

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