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

Re: Delete *for real* from a repository

From: Andy Levy <andy.levy_at_gmail.com>
Date: Thu, 17 Sep 2009 11:25:49 -0400

On Thu, Sep 17, 2009 at 11:08, <russ_at_vshift.com> wrote:
> This is also probably one of the major reasons that most developers are switching to GIT... SVN came out to be from the ground up redesign of CVS and now GIT seems to have come out as a redesign of SVN. Looks like if things don't shape up soon with the SVN development, GIT will push SVN into obscurity.

I won't even consider leaving SVN for GIT until GIT supports Windows
as easily as SVN does.

> -----Original Message-----
> From: Tony Sweeney <tsweeney_at_omnifone.com>
>
> Date: Thu, 17 Sep 2009 15:56:08
> To: Bob Archer<bob.archer_at_amsi.com>; Jo Support<jo.support_at_gmail.com>; <users_at_subversion.tigris.org>
> Subject: RE: Delete *for real* from a repository
>
>
>> -----Original Message-----
>> From: Bob Archer [mailto:bob.archer_at_amsi.com]
>> Sent: 17 September 2009 15:31
>> To: Jo Support; users_at_subversion.tigris.org
>> Subject: RE: Delete *for real* from a repository
>>
>> > I'm using SVN 1.4.4 on CentOS and I need - for
>> administration purpouse
>> > - to delete *for real* a whole directory from the repository. As
>> > everybody knows, deleting using the "delete" command just
>> adds a new
>> > revision, without freeing space on the disc. I googled my issue,
>> > reading that it's impossible to delete for real something on a
>> > repository, and a filtered dump with a following reimport is needed.
>>
>> With the current version you need to think of the repository
>> as create/update only and plan for this in capacity planning.
>> The bottom line is that things are going to be added to your
>> repository that you don't want in there. If you go and
>> dump/load every time this happens you are going to drive
>> yourself crazy. You just have to be ok with it.
>>
>> There are many requests to add this, but frankly I consider
>> it a low priority... at least for me. To others it is a high
>> priority. I would rather see the developers would on stuff
>> like WC-ng and better history for move/renames and perhaps
>> better branch/merge functions like brining in some of the
>> features of the svncopy.pl utility.
>
> Just for perspective, Perforce has had an obliterate command since at
> least 1997, and the ability to obliterate files was one of the first and
> most heavily voted for system enhancement requests (the first commercial
> release of Perforce was in 1996).  When you have paying customers, you
> tend to implement what they want.
>
> Tony.
>
>>
>> BOb
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&
>> dsMessageId=2396022
>>
>> To unsubscribe from this discussion, e-mail:
>> [users-unsubscribe_at_subversion.tigris.org].
>>
>>______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit
>> http://www.messagelabs.com/email
>>______________________________________________________________________
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396035
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396046
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-17 17:26:38 CEST

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

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