On Thu, 2010-02-04 at 17:25 +0100, Lieven Govaerts wrote: > On Thu, Jan 28, 2010 at 1:00 PM, Julian Foad <julian.f...@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
