As an end-user of this stuff (1) is all I need. Y'all could take
another few years doing (2) and (3) for all I care ;-)
In respect of our immediate need for obliterate, I think that is
past. We'll be posting a patch for tree_conflicts.c today that gets
us through our issue with merge for now. Its not perhaps something
we'd want to rely on long term, so svn committers are going to want to
> Yes, I agree that marking a directory as hidden from clients is a
> 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
> 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-26 02:49:34 CEST