On Thu, 2010-02-04 at 17:25 +0100, Lieven Govaerts wrote:
> 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.
Thanks, and I would certainly benefit from any assistance with testing
you can give.
- Julian
Received on 2010-02-04 19:32:24 CET