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
redo it.
Regards,
- Paul
>>
>>
>
> 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
> case.
>
> 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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398891
Received on 2009-09-26 02:49:34 CEST