[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Obliterate - milestone 1 reached: the most basic obliteration

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Thu, 4 Feb 2010 17:25:51 +0100

On Thu, Jan 28, 2010 at 1:00 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Hi, fans of "obliterate".
>
> I am pleased to announce that a very restricted form of "svn obliterate"
> is now working.
>
> According to the plan
> <http://svn.apache.org/repos/asf/subversion/trunk/notes/obliterate/plan-milestones.html>, I intended to get a simple kind of obliteration (last version of a node) working by the end of January. Something like this is working now. Let me explain exactly what the status is.
>
> The present "svn obliterate" command in trunk (which is compiled in if
> the macro SVN_WITH_EXPERIMENTAL_OBLITERATE is defined) can now remove a
> file node from the head revision. Yes, only from the head revision,
> which isn't much use in a busy repository, I know.
>
> This is implemented only in BDB as yet; I am deferring FSFS support till
> later because development for BDB is more efficient in terms of my
> effort. I will update the plan to reflect this change.
>
[..]
>
> NEXT STEPS
>
> More important than (1) and (2) is extending the support to obliterating
> older revisions. My first step there is to make it adjust any immediate
> successor (the same node id in the next revision) to take account of the
> change. After that I will look at searching for all future copies of the
> node, which is facilitated by the "successor-ids" table as implemented
> in the "fs-successor-ids" branch.
>
> Philip Martin has looked at an important angle of development which is
> to obliterate a file's content rather than the existence of the node
> itself. Deleting a file's content by replacing its content
> representation in the DB can be done far less invasively (with far less
> complexity of implementation) than removing a directory entry, and at
> the same time this changes all successive revisions of the file and all
> copies of it, which is often what the user wants. That provides an
> efficient way of obliterating the same file across a large range of
> revisions. However there are some difficulties with it. I will be
> investigating how best to gain the advantages of that approach.
>

Just wanted to say: keep up the good work.

I'll try to follow your changes a bit more, as soon as you have
something implemented in fsfs.

In the meantime, if I find a bit of time I want to look at the test
framework for the obliterate tests, as I'm a bit worried it will be
difficult to test all the obliterate details efficiently with our
current framework.

Lieven
Received on 2010-02-04 17:26:45 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.