Idea for effective 'obliterate', previously on issue 516

[Paul Hammant <pa...@hammant.org>]

Folks,

Julian Foad has suggested that I keep this discussion on the dev list  
(rather than on bug tracker as I had started)

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

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.

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.

Regards,

- Paul

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398538

Re: Idea for effective 'obliterate', previously on issue 516

[Paul Hammant <pa...@hammant.org>]

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

Re: Idea for effective 'obliterate', previously on issue 516

[Julian Foad <ju...@btopenworld.com>]

On Tue, 2009-09-22, Paul Hammant wrote:
> Folks,
> 
> 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  
> hard.
> 
> 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
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.

Thanks.
- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398571