On Tue, 2009-09-22, Paul Hammant wrote:
> Julian Foad has suggested that I keep this discussion on the dev list
> (rather than on bug tracker as I had started)
Thank you for emailing here.
> I get that fsfs does not make it easy to actually delete apparent
> directories on the server side, given the nature of the revs folder
> and the deltas within it. That would mean that 'obliterate' would be
> However, one thing that could work for some people is the apparent
> obliteration of the folder. Meaning, the svn client (checkout, up,
> log, pl, etc) sees no directory in that location. On the server side
> it would still be there, but some new property marks it as "hidden
> from all clients", and thus no client would see it.
Yes, I agree that marking a directory as hidden from clients is a valid
and useful part of an "obliterate" design. I have categorized the use
cases for "Obliterate" into three groups:
(1) hide data from clients
(2) recover disk space on the server
(3) keep only the latest N revisions of certain files
In terms of implementation, (1) is effectively a pre-requisite for (2)
in the sense that if (1) were implemented first, (2) could then be
implemented "behind" it, so I am well aware that it is an important
At the moment I am starting to design (1) while looking ahead to (2),
and (subject to further input on priorities) I expect to proceed in the
order (1), (2) and then perhaps (3).
> Right now I need this feature because a merge is still barfing (tree
> conflict; latests 1.6.x-R38000 self-built executable) on this
> directory even though I have committed a delete to both the source
> trunk and destination branch.
>From this description it sounds like you are hitting a bug in
Subversion, in which case first and foremost you need a bug fix.
Obliterate is not intended to be a way to work around problems like
that, so it sounds very odd to read that you "need this feature
because...". When it exists you are welcome to use it that way if you
choose, of course.
Received on 2009-09-22 19:08:56 CEST