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. Lieven
