[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Paul Hammant <paul_at_hammant.org>
Date: Wed, 23 Sep 2009 08:48:28 -0500

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.


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

Received on 2009-09-26 02:49:34 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.